When a value is not found in the settings table, get the value instead from process.env. The rest of the application, instead of directly accessing process.env, will get settings through appSettings.js. Essentially, this does away with the hard-coded settings list we have. If an admin adds a setting, it can override the .env file without any additional work on our part.
We may still want to whitelist (or blacklist) which values from process.env can be overridden if research shows that some likely settings changes can easily render the application FUBAR.
It would also be advisable that appSettings raise an event to notify other interested modules that a setting has changed, since other modules may cache settings values rather than reading them from the database every time they are needed.
snarfblam
commented
6 years ago
When a value is not found in the
settingstable, get the value instead from process.env. The rest of the application, instead of directly accessing process.env, will get settings through appSettings.js. Essentially, this does away with the hard-coded settings list we have. If an admin adds a setting, it can override the .env file without any additional work on our part.We may still want to whitelist (or blacklist) which values from process.env can be overridden if research shows that some likely settings changes can easily render the application FUBAR.
It would also be advisable that appSettings raise an event to notify other interested modules that a setting has changed, since other modules may cache settings values rather than reading them from the database every time they are needed.