4 ms·

Mostly configuration stored in the database (who configures the database) or 3rd party configuration services without an SLA and config files that are either pr

by edem 6y ago

Mostly configuration stored in the database (who configures the database) or 3rd party configuration services without an SLA and config files that are either present or not. Env vars are really simple since they are completely decoupled from the app and you can have default values for all of them. You just need a single class that loads all config on startup and you can go from there (or fail if you don't have the mandatory vars).

emodendroket 6y ago
They also work well with serverless environments, containers, etc., which can’t be said for some alternatives.
- HelloNurse 6y ago
  Environment variables are also more portable and cheaper/simpler than a DBMS, a LDAP service, an application server's proprietary configuration repository, etc. without being weaker at specifying simple configuration values. In practical terms, specifying environment variables in cleanly isolated and composable layers (defaults by user, a specific terminal session, a script that call another script or the useful program) is a major advantage over more enterprisey and monolithic mechanisms.
deleted 6y ago
[deleted]
KptMarchewa 6y ago
>who configures the database or, what configures the database connection
- edem 6y ago
  I forgot the question mark: (who configures the database?). So it is about the problem that if you have your configs in a database then you will carry the additional burden to separately set up databases for each environment....it is like trying to put the hash of an image on the image.
exclusiv 6y ago
Bingo. The author's title is unfortunate: "Never use environment variables for configuration" Not everyone is writing CLI scripts. Some are writing multi-environment software for the web. Some people care about git and distributed teams. Let's say you backup and migrate a db which has config in the db. Well your other environment is using the wrong config! Now you're possibly using prod SMTP credentials and sending notifications to the wrong people because all you wanted to do was have live content and do some testing or show debug messages because you're on a test environment. Web frameworks which have the HTTP host in the database drive me nuts. Why do you need that? Your webserver is responding on a domain name. Why do some store the absolute url in the db. It makes no sense. For the 3 people that want to serve up domainA.com but have all links readily be domainB.com maybe that makes sense. Don't get burned people. For most things, just ignore this article, keep your secrets out of version control and keep your code ready to deploy to multiple environments. Decouple that. Your app should be able to work with various configurable services (SMTP, push notifications, database, etc) and you don't want that config in version control. So either a file that's outside of version control with variables you set per environment or actual server environment variables. Environment variables in many web languages are just namespaced globals. Still better than global variables. They serve a purpose. The author has this: int first_argument; int second_argument; void add_numbers(void) { return first_argument + second_argument; } While it helps the author's agenda, that's not a legitimate example. A real example would be a service provider which a developer would understand to have the sole purpose of pulling from environment or config values to initialize. You wanted a Twilio client? Well, we know it needs some keys. Use environment variables. Boom. Everywhere you ask for this Twilio client you get the same instance with the config that that environment needs. This is not a problem. It works well. Better than any alternative. Author also says this "Environment variables is exactly this: mutable global state." For some CLI applications maybe. But for web languages this is not accurate. Some languages, yes, you can mutate the env variables at runtime. But your code shouldn't rely on any mutable env vars. You can load those env vars into a config. Even cache it. Not allow mutations. Many modern frameworks support this or you could implement it yourself. And if you have a CLI that really needs to be explicit about the environment vars to run? And not be different the next time you call it with no env vars? Well maybe take those as arguments? Plenty of CLI apps that store config in json and have a wizard to set those credentials. AWS CLI as an example. Now you got JSON as the author wanted. That can work across platforms. But guess what? You work on multiple clients and hosts and next time you call it? Well you might not be expecting that it had config for another client or app. Same problem. The state was mutated. You called it again. You potentially got burned. Now you have to do the CLI wizard to reconfigure. Or you pass in explicit params if allowed. Definitely a consideration if you are writing such a program. Do you make it explicit with arguments and options? Load from ENV vars? Have some CLI wizard and save to JSON? The author's suggestion of JSON is no reason to toss out ENV vars. Just solves slight differences between Windows and Unix. Which is why you can program a CLI wizard if you care about that problem. We don't need to say no to env vars because we want CLI app users across different platforms to have the exact same API. Setting up a JSON file is really lame to use a program. Which is why you see cli wizards when you run them. Or things like "aws configure". And you still have CLI arguments and options availabe.
edem 6y ago
I left the question mark out. It is "(who configures the database?)".

by edem 6y ago

emodendroket 6y ago

They also work well with serverless environments, containers, etc., which can’t be said for some alternatives.

HelloNurse 6y ago
Environment variables are also more portable and cheaper/simpler than a DBMS, a LDAP service, an application server's proprietary configuration repository, etc. without being weaker at specifying simple configuration values. In practical terms, specifying environment variables in cleanly isolated and composable layers (defaults by user, a specific terminal session, a script that call another script or the useful program) is a major advantage over more enterprisey and monolithic mechanisms.

deleted 6y ago

[deleted]

KptMarchewa 6y ago

>who configures the database or, what configures the database connection

edem 6y ago
I forgot the question mark: (who configures the database?). So it is about the problem that if you have your configs in a database then you will carry the additional burden to separately set up databases for each environment....it is like trying to put the hash of an image on the image.

exclusiv 6y ago

Bingo. The author's title is unfortunate: "Never use environment variables for configuration" Not everyone is writing CLI scripts. Some are writing multi-environment software for the web. Some people care about git and distributed teams. Let's say you backup and migrate a db which has config in the db. Well your other environment is using the wrong config! Now you're possibly using prod SMTP credentials and sending notifications to the wrong people because all you wanted to do was have live content and do some testing or show debug messages because you're on a test environment. Web frameworks which have the HTTP host in the database drive me nuts. Why do you need that? Your webserver is responding on a domain name. Why do some store the absolute url in the db. It makes no sense. For the 3 people that want to serve up domainA.com but have all links readily be domainB.com maybe that makes sense. Don't get burned people. For most things, just ignore this article, keep your secrets out of version control and keep your code ready to deploy to multiple environments. Decouple that. Your app should be able to work with various configurable services (SMTP, push notifications, database, etc) and you don't want that config in version control. So either a file that's outside of version control with variables you set per environment or actual server environment variables. Environment variables in many web languages are just namespaced globals. Still better than global variables. They serve a purpose. The author has this: int first_argument; int second_argument; void add_numbers(void) { return first_argument + second_argument; } While it helps the author's agenda, that's not a legitimate example. A real example would be a service provider which a developer would understand to have the sole purpose of pulling from environment or config values to initialize. You wanted a Twilio client? Well, we know it needs some keys. Use environment variables. Boom. Everywhere you ask for this Twilio client you get the same instance with the config that that environment needs. This is not a problem. It works well. Better than any alternative. Author also says this "Environment variables is exactly this: mutable global state." For some CLI applications maybe. But for web languages this is not accurate. Some languages, yes, you can mutate the env variables at runtime. But your code shouldn't rely on any mutable env vars. You can load those env vars into a config. Even cache it. Not allow mutations. Many modern frameworks support this or you could implement it yourself. And if you have a CLI that really needs to be explicit about the environment vars to run? And not be different the next time you call it with no env vars? Well maybe take those as arguments? Plenty of CLI apps that store config in json and have a wizard to set those credentials. AWS CLI as an example. Now you got JSON as the author wanted. That can work across platforms. But guess what? You work on multiple clients and hosts and next time you call it? Well you might not be expecting that it had config for another client or app. Same problem. The state was mutated. You called it again. You potentially got burned. Now you have to do the CLI wizard to reconfigure. Or you pass in explicit params if allowed. Definitely a consideration if you are writing such a program. Do you make it explicit with arguments and options? Load from ENV vars? Have some CLI wizard and save to JSON? The author's suggestion of JSON is no reason to toss out ENV vars. Just solves slight differences between Windows and Unix. Which is why you can program a CLI wizard if you care about that problem. We don't need to say no to env vars because we want CLI app users across different platforms to have the exact same API. Setting up a JSON file is really lame to use a program. Which is why you see cli wizards when you run them. Or things like "aws configure". And you still have CLI arguments and options availabe.

edem 6y ago

I left the question mark out. It is "(who configures the database?)".