5 ms·
> application with reasonable defaults defaults for dev or defaults for prod :) If you say dev, you will eventually break prod. And prod defaults may not make
by sethammons 3y ago
> application with reasonable defaults
defaults for dev or defaults for prod :)
If you say dev, you will eventually break prod. And prod defaults may not make _any_ sense for dev.
- berkes 3y ago> And prod defaults may not make _any_ sense for dev They are actually rather dangerous even. You certainly don't want your dev (or test CI) to reset the database if you are accidentally connected to prod. Same for email-endpoints, CDN, a message-bus, etc. I've had my share of near-heart-attacks where I send out 10k emails or thousands of payments on actual production services because of a spagetti config loaders with stuff that boils down to `if (getHostname() === "localhost") { include("dev.json") } else { include("prod.json") }`. I'd prefer a hundred .envs and whatnots to avoid just one of these scares.
- jameshart 3y agoMy approach is: - defaults are sensible (safe and secure) defaults for prod - prod secrets are only available in the prod environment So if you accidentally end up trying to run with the prod settings in a nonproduction environment it might try and access the prod database server... but it won't get anywhere because it doesn't have those secrets.