Is your feature request related to a problem? Please describe.
Currently the configuration file is loaded from a config file, which is a good starting point. However, that would mean fixing your topology, which is rarely the case in production.
New service endpoints may be required to be added
Existing endpoint may need to be deleted / updated
Configration changes may be needed for request/response processing
Timing changes (such as cacheTTL, timeouts etc. may need to be revised etc.)
Describe the solution you'd like
Host the configuration file in a database, and let users do CRUD on the config through UI.
You can "load" the config once on start, as you are doing currently, and "reload" it whenever the database records change. (Most databases, including postgres, currently support ways for monitoring and getting notified whenever records in the DB change)
Describe alternatives you've considered
The documentation suggests blue/green deployment methodology, which is not really efficient nor cost-effective.
Additional context
Changes to the config (network topology) in production are more frequent than one can afford with static deployment strategies (such as blue/green), one of the reasons why most prominent API gateways in the market currently use Databases to store their config.
Loading and caching the config from the DB once on start, and refreshing (only the changed parts) when the DB changes, gives performance (of static configs) without losing the convenience (being able to edit the configs on the fly)
This issue was marked as resolved a long time ago and now has been automatically locked as there has not been any recent activity after it. You can still open a new issue and reference this link.
Is your feature request related to a problem? Please describe. Currently the configuration file is loaded from a config file, which is a good starting point. However, that would mean fixing your topology, which is rarely the case in production.
Describe the solution you'd like
Describe alternatives you've considered The documentation suggests blue/green deployment methodology, which is not really efficient nor cost-effective.
Additional context