config file

[mattgstevens]

im a fan of using "dotenv" to load a .env file that holds secrets & configs that should not be checked into the repo.

a first pass of things we might want: DATABASE_URL=postgres://username>:<password>@localhost:5432/<db_name LOG_LEVEL=debug NODE_ENV=development PORT=5000 REDIS_URL=redis://:@localhost:6379 TZ=UTC

[fromheten]

I see why this can be a solution to a problem, but do we have the problem or is this just adding one more thing to keep in your head when coding? So far we

• always run the database on the same machine - when we split that task up (after thousands of users) it can be useful, but now not really
• have never needed log levels
• have no development/prod enviroment - the longer we can avoid that complexity the better. It's really only needed for some IO things - and things that write and read from places. Since most of our app is pure functions, we can prob stay free from any such worries for a long time
• always run the app on port 3000 - we don't need to run on different ports at any time
• redis is the database
• We don't use dates nor time zones - the only notion of time is timestamps, but they are always in UTC. And if we introduce anything that has with time and date to do (god save us from that) we should always use UTC. Only the UI can display localized times - just like i18n for language.

Another way to archive the same thing could be to use arguments to the app, that are loaded with ARGV. We could even let the argument be a JSON data structure, so we can just pass in a map of initialization data. That would fit with our functional way, as opposed to writing into the enviroment key/value thingy and reading from there. So instead of $ LOG_LEVEL=debug node my-app.js, it would be $ node my-app.js --logLevel debug.

In conclusion, I think we should close this ticket since it is a solution to a problem we are not experiencing. What do you think?

[mattgstevens]

ok I reached for my template and extracted things I thought were relevant.

What lead me here is the TZ env var, as this should be set so our Dates are normalized. Taking a second pass on the code base and we only use Date.now() which means we won't have this problem (new Date() may not be UTC)