Common Configuration server

[kohsah]

Currently configuration is specified on a server component (e.g. editor-fe or portal-fe) and shared with the client over http. However this still implies a duplication of configuration across server components.

We need to a add a common configuration service that returns shared confiuration over http as json. and individual server components can access it.

This may still imply duplication of configuration services e.g. if editor and portal server components are deployed on different boxes - but it still provides better separation of configuration from code.

NOTE that clients will never access the config server directly but only via specific server side apis provided by their service components

[ccsmart]

The proposal would be that a service is considered, comparable to ie windows registry, that holds configuration data. Namely and as an initial example, assignment of hostnames and ports where the different services of Gawati will listen, as any service could be installed on a dedicated host or docker container and different ports could be assigned for diffferent instances of the same service for parallel installations of dev and prod environments or in a multi tenant setup.

The configuration data would preferably be used for both, initial self configuration of any given service, ie answering the question which port the starting service is meant to bind to and listen, as well as where other services are to be accessed as part of request execution.

A successful implementation would allow to manage a deployed system by adjusting configuration data in the configuration server exclusively.

The only information given directly to gawati processes / clients of the configuration server should be how to acccess / where to find the configuration server by providing the gawati service a configuration URL at startup, ie https://myconfig.gawati.org/dev/

That would also mean, 1 config server can hold configuration data of more than 1 Gawati setup.

[kohsah]

@ccsmart to me this config server is imply a JSON config file deployed over http. So it strictily speaking does not need a specific service ... just a JSON file served over http from a predictable host / domain ?

The only point of contention would be that some information is private (requested by server side applications) and some information is public (i.e. requested by client applications) . This split is there even in the current gawati.json config in portal-fe - maybe we just have one config file - and different branches of which (private , public) are served by specific expected domains .