Stale Router Settings

[kane-mason]

I am able to update settings in the admin panel, and the router.settings is refreshed by virtue of the changed listener in listeners.js (PS there is a TODO on line 17 that should prob be done).

However there is no way to programatically update a setting server side by means of the api.bd.settings.udpate api, with the router.settings being refreshed.

I was thinking, like we have a getSetting utility, we could create a setSetting utility which would make the update and refresh the router.settings

[kane-mason]

or just reread settings everytime getSetting is called, and remove req.settings in favor of getSetting

[kane-mason]

@thomas4019 id be happy to do PR for this if you could advise which direction you like? Something else to consider is having two instances of expressa where an update on one, may not trigger an update on the other, in which case my second comment (or similar) is likely preferred.

Or possibly adding a second utility getDynamicSetting which rereads settings from db every invocation - used exclusively for those settings values you know may change

[thomas4019]

@kane-mason thanks for brining this up. I like the idea of a setSetting utility for integrators to use. Instead of changing getSetting or adding getDynamicSetting what do you think of re-reading the settings from the database at the beginning of each request? I think it could be added to the beginning of attachVariablesToReq and that way we only do it at most once per API call which should scale well.

[kane-mason]

Mmmmm the more i think of this the more i dont like performing another read from the db on every request.

Will carry on thinking, but for now i wrote a utlity refreshSettings which i call before i try and retrieve a setting i know may have changed

[kane-mason]

A work around for this could be that settings collection is readonly - this could be a rule written into expressa using permissions, so a user may opt out of the feature if they choose. but we would document the risks.

OR we remove the invokation of getSetting from every request and leave it as a util but make it async (breaking change). I noticed getSetting is only called within expressa for the jwt_secret which is not expected to change, and we could document that changing it requires a api restart. logging_level also used but not expected to change. So we could just store those values in local variables at api start and bypass the need for getSetting invocation in every request

[thomas4019]

@kane-mason Can you provide an example of when you change a setting? Would it usually be fine to wait for a new deploy for the changes to take affect?

I think I like the idea of read only settings in general. Having a setSetting is error prone once one is running multiple servers like you mentioned.

[kane-mason]

Sorry @thomas4019 i missed this!

So i have made my settings read only by way of permissions and it is working nicely.

I created a collection to store configuration that i wish to update dynamically - in my case its refresh tokens from an external api

[kane-mason]

i think we should make these read only by default