Should we directly read environment variables when/where we need them?

Question

Why most frameworks (at least in PHP. I suppose in other languages, too) use the environment variables to set a corresponding configuration parameter and then access the value through a config object/function (e.g config('mysql.passqord') or $config->get('mysql.password') ). I won't argue on whether environment variables are good or bad. Let's say we decided to put some configuration values in environment variables. What is wrong with directly reading the environment variable (e.g env('MYSQL_PASSWORD') ) in any place of your code you need them ?

Is it just that we want to have a unified way to access all configuration parameters ? Is there any other more important reason ?

Answer 1

This is because the rest of the code should rely on abstraction - it does not matter if configuration comes from env variables, database, file or a magic ball. Then it is because of encapsulation - the dependency between the code and runtime environment is encapsulated inside the config class.

Answer 2

For server side code, reading all the environment variables on startup allows detection of missing variables to be handled by either refusing to start or setting a default value. Otherwise your code may fail later when the environment variables is actually used, or become cluttered with default setting code possibly repeated in multiple places.

Answer 3

It is best to read all configuration in one place in the code. Reading it in multiple places is a path to madness. If you do this, then when your code grows to be bigger than a few screens long, it will start becoming difficult to debug and document things with config parameters scattered all over.

Also, environment variables are a security risk, not in that you shouldn't use them, but in that you should sanitize them before use to make sure there isn't bad data in them that could cause a security problem or an unexpected crash. If you read them all over the place, you will have to repeat the sanitation in each place and also risk forgetting to do it in some of them.

Also, what if you decide to configure it in a different way later? If you had it all in one place, it is one place to modify. If it's scattered, you'll be duplicating the configuration code and fixing it in multiple places.

It's just a cleaner more readable safer easier to maintain design to read configuration, especially external (user supplied) parameters like environment variables, all in one place.

The only good argument against this is that if the code is short (like, a screen full of code), and you are very very sure it will never grow larger, then it may not be worth the overhead of organizing the code to carefully read all your parameters in one place.

Answer 4

Your application lives in some environment. Some of it comes from environment variables. Some comes from the actual environment, like what kind of your computer is your application running on. Some is hard coded for different customers (so they can’t change it).

You should have a class or something that answers questions about the environment. That call will read environment variables for some parts of the environment, and use other methods for other parts. The rest of the application should not know anything about it.

(In my application I have configuration that may be under control of the user’s employer, some can be set by the user, some can be hard coded in a build for a specific customer, some can be in configuration. You want to call one class to get the configuration, because the code can be complicated).