Highly changing environment variables shouldn't be made constant

[anshgoyalevil]

We are relying on the Constants such as RECAPTCHA_SECRET_KEY, MAIL_USERNAME, MAIL_PASSWORD```, etc. inside the Talawa API.

When we start the node server, all of the constants are loaded from the environment variables.

What's the problem here?

• Start the Talawa API in your local machine, but don't add mail variables.
• Now, once it starts, add the mail variables while server is running.
• Now try sending an email using forgot password feature on talawa admin.
• Email sending will fail

This is because even if there exists mail variables now but the server loads the value undefined in place of mail variables initially. You would have to stop and start the node server again.

This could seem like an easy task if we look at it inside local machine, but when we scale it to production, this will result in the server downtime.

An admin may want to change the environment variable while the server is running. This couldn't be achieved since all environment variables are loaded during the initial server boot, and a typical cloud or vps server takes about 5-10 minutes to restart the node process. This may also result in data loss if the storage system is non persistent.
Also, most cloud or vps providers offer a 99.99 SLA (~ 4 minutes in a year) which will become useless in such a case.

What can be the solution?

• Either we should create a function which reloads the constants from updated environment variables. This may be done by creating a graphQL resolver which triggers the function to reload constants.
• We can also use some environment variables directly, which tend to be changed frequently.
• Your suggestions

Provide your suggestions on what could be the possible solution or, if we should stick to the current talawa api constants system only.

[anshgoyalevil]

@xoldyckk @palisadoes @DMills27

Please provide your feedback over this.

[xoldd]

@anshgoyalevil I've never heard anything about dynamically loading and injecting environment variables inside a running server.

This is a fairly common problem and it's simply solved by having a function run at server boot time to check for existence of these environment variables which are critical at runtime. It's not only limited to environment variables, you also test whether the 3rd party services you're using are actually reachable during server boot, because you can simply provide a dummy environement variable to escape the environment variables function check. If any of the required environment variables are not provided or the services are not reachable the server boot up fails.

[anshgoyalevil]

@xoldyckk

How could we handle the environment variables which are not critical, but may later be added.

And, what if we want to change the critical environment variables, even if previous ones work, and server is running.

[xoldd]

@anshgoyalevil IDK. Never heard of anyone doing this, and it'd definetely be a risky thing to do.

[anshgoyalevil]

Okay. I guess, we should stick with the current approach. Maybe we can decide to do something like this in future after getting end users feedback.