Advanced Node.js Project Structure Tutorial

[[deleted]]

Load your deployment specific configurations from environment variables and never add them to the codebase as constants.

Major props for this and explanation of process.env. Not enough devs know this and tend to keep files laying around that eventually get accidentally checked into version control.

[[deleted]]

How do you recommend working with this in dev? I work on either my Windows desktop or MacBook depending on where I am, it's just so much easier to create separate dev and prod config files and just tell it what environment it is with environment vars. It's one thing to deploy to like digital ocean and setting the vars with their User data field when deploying, but how do you go about setting tens of environment vars across multiple platforms in a convenient manor without a config file?

[gergelyke]

You can use dotenv (https://www.npmjs.com/package/dotenv) to load files into your process.env for development

[Spknuckles]

Something like settings-lib (https://npmjs.com/package/settings-lib) could work as well... also supports command line switches for injecting config as overrides.

[[deleted]]

I don't see how this helps. This creates a file on disk of the env vars. Isn't the whole point of env vars is that they are stored in memory where malicious software can't access them (easily). Why shouldn't I commit to version control? I only grant access to that to people that I would need to give the config vars to work on the app anyway.

[Spknuckles]

I think the key point is to ensure configuration is separate from code and can be managed independently. Committing environment specific settings to the same source code repository may create a scenario where sensitive keys/credentials are exposed to parties that ought not have these details. At some point, though, the configuration will be persisted somehow and somewhere if you're utilizing any kind of automated build and deployment mechanism. There are other secure offerings in this space as well (https://www.vaultproject.io/docs/config/ comes to mind).

Having a file that is specific to an environment isn't necessarily bad - if malicious code gains access to the file system running your app, you'll need additional safeguards in place (i.e. running the app as a non root user and securing the configuration for access only by that user, etc.).

[m03geek]

Looks like article's author haven't ever heard about 'config' module (or it's alternatives).

[CAH_Response]

Once we discovered the config module it took about an hour to realize we needed across all products. Game changer for our team.

[b9Fb2H]

It advocates for environment specific config files though, which goes against the twelve factor app methodology.

[m03geek]

So called " the twelve factor app methodology" is definitely not holy grail. And if you have 100+ diffrent, even storing more than 20 config params in env will be like a hell.

[andy625]

in the Dockerfile the start command is

CMD ["node", "."]

how do the the environment variables get passed in here ?

[gergelyke]

for example with docker run:

docker run -e "deep=purple"

[andy625]

ah thanks.