On Thu, Feb 9, 2023 at 5:05 PM Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote:
On 2/9/23 07:30, Dominique Devienne wrote:
> In a normally 2-tier system, where "desktop" native apps connect
> directly to PostgreSQL to access data, some things must be mediated via
> a middle-tier service (i.e. 3-tier architecture). That service is HTTP
> based thus clients (the "desktop" native apps) must know the URL
> (host+port+path) of a server providing the requested service.
Is there more then one server providing the same service?
Yes. That was my PS: basically. The client can connect to any one, randomly.
We need at least one of course. But there could me more than 1, yes.
> Since clients must already have access to PostgreSQL to operate, I
> wanted to add a table in PostgreSQL for services, and server(s) on
> startup (probably using a random port) would register in that table, and
> deregister on shutdown. Also, since crashes are a fact of life, the
> server would regularly update the DB with a "heartbeat" on some
> frequency (e.g. 1s?), so clients would select (or see) only registered
> services with a "fresh enough" heartbeat timestamp.
Would it no be easier to not have random ports and just attempt
connections to the servers either:
1) In the client with reattempt to different port on failure.
2) From Postgres server and update table to have current up servers.
I'm sorry, but I'm not following. Can you perhaps rephrase?
Regarding ports, once you have registration of services, just seems easier to me to NOT have a fixed port,
and let the host assign any port to the HTTP server. Those servers are not user-facing directly, from the client
side, it calls an API and lookup of the service and connection to the HTTP server is transparent is an implementation
detail, so the port used doesn't matter. In-DB registration of (HTTP) servers makes the while URL an implementation detail.
