I've seen a lot of node projects that have a .env file and then use the dotenv module to set your values on the process.ENV object.. things like keys and secrets and other constants needed throughout the app.I have seen this touted as a best practice because it follows 12 factor app principles and things like that, but it's just not making sense to me. Normally what I've always used is 2 config files, one for dev and one for production. The production config file gets all of it's values by accessing process.ENV, but the development config file has all of it's values hardcoded. Depending on the value of process.env.NODE_ENV, I choose whether to use the dev config object or the prod config object.All of the keys, secrets, and constants in the dev config have zero affect on the production environment, so even if a dev wants to be malicious with an API key or something, it really doesn't have an effect on anything of value.Because of all of the above, I'm failing to see the benefits of using the .env file. From what I've seen, the project normally has a dummy file like .env_example to provide guidance to anyone using the code, but it's their responsibility to create a .env file and fill it with key-value pairs. Also, it's promoted as a benefit to not have this file checked into git, which is why everyone needs to create their own .env file in the first place. This seems like a lot of extra work to me, and I'm not really seeing how it's more secure than using the config example I described above.I have a feeling there is more to using the .env file than I am realizing, so I'm looking for advice on this matter. I've never worked on large teams or big open source projects, so I feel I may be missing something here.Appreciate the help.
Submitted May 24, 2017 at 02:43AM by m9js
No comments:
Post a Comment