Since most queries just return a nested data structure, using a JSON transport layer in between should be fine.²

I'd start googling for REST and SQL.°

I don't know the nature of your centralized data, but propably you'll even only need some static JSON files which are updated regularly from SQL?

update

°) especially ODATA

²) kind of

• -> post request named query
• -> + bind variables (placeholders)
• server: executes prepared statement
• runs ->fetchall_hashref or ->fetchall_arrayref
• to_json($ref)
• <- JSON
• client: $ref=from_json(JSON)

³) and HTTP(S) means far less problems with firewalls.

Thanks. Interesting thoughts. My data structure is quite simple. Two columns: 1. column to match a query, 2. columns contains results. Just reading. Any data maintenance is done in SQL. Your description of the process seems what I am looking for. Just searching if there are modules I can use in order to not reinvent the wheel (and probably build errors in it).

Plz have a look at the sketched communication flow in my second footnote (updated).

A CGI using JSON and DBI to run just 2 or 3 prepared statements returning AoAs should have less overhead than configuring a full REST/ODATA layer.

Without knowing your app I can't judge how complicated it's supposed to become later, hence justifying the long term investment into abstraction.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

update

NB: if you put these SQL-statements into a separate module you can use and test them directly. The additional CGI/JSON layer would be transparent.

Implemented 1 to 1. Nice! Thank you!

Great! YW! :)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

I guess this is not good practice.

Hi, you are right about that!

The reason web services in general are so popular is that HTTP is just a very efficient, time-tested way of handling stateless server-client communication, like SQL queries.

Adding the capability to your app to make HTTP requests is trivial -- I would use HTTP::Tiny which is in core Perl and has a very user-friendly interface.

To serve responses I would install a modern Perl web application. There are lots of super-lightweight ones including HTTP::Server::Simple, but I would recommend going with something a little more feature-rich so it can handle your database needs natively, along with logging, authentication, tx encryption (https), etc etc. My choice would be Dancer2, which I like in part because it is very pluggable, meaning you can run it very lightweight with very lightweight code. Not least of the useful features is Dancer2::Plugin::Database. Once you've configured your Dancer app with your database settings, you have access to the DB in your code via the database keyword, and can make simple queries with sugar methods like quick_select.

Here's an oversimplified and contrived use case. Suppose you are providing the daily closing stock prices for some market and you have the important data in a table called price. The user has to provide the stock symbol and the date for which the price is requested. Your app will make an HTTP request to your server using a URL like https://your-backend.com/GOOG/date/2018-11-05, and get a neat response of {"price":"1057.79"}.

The entire server code for that is:

use Dancer2;
use Dancer2::Plugin::Database;

set serializer => 'JSON';

get '/:stock/date/:date' => sub {
    database->quick_select('price', {
        stock => params->{stock},
        date  => params->{date},
    }),
};
 
dance;
[download]

plugins:
    Database:
        driver:        'mysql'
        database:      'test'
        host:          'localhost'
        port:          3306
        username:      'your_app_id'
        password:      's3kr1t'
        on_connect_do: ["SET NAMES 'utf8'", "SET CHARACTER SET 'utf8'"
+ ]
        dbi_params:
            RaiseError: 1
            AutoCommit: 1
[download]

Hope this helps!