🏁
Best Practices
  • Introduction
  • The Big Picture
    • Principles
      • Software engineers solve business problems
      • Programming is a social activity
      • Attention is the most precious resource in a project
      • Simplicity is the best ally in the long run
      • The only problem to solve is the one we have today
    • Architecture
      • Domain
      • Services
      • Persistence
      • HTTP
      • UI
    • Naming
  • Constraints
    • TypeScript
    • Monorepo
    • Monolith
    • Versioning
  • Source code
    • Declarative programming
    • The README
    • Modules
    • Folder structure
    • Code formatting
    • Code comments
  • The Outside World
    • Runtime configuration
    • Logging
  • Testing
    • The purpose of testing
      • End-to-end tests
      • Integration tests
      • Unit tests
  • Tools
    • Git
  • Resources
    • Resources
Powered by GitBook
On this page

Was this helpful?

  1. The Outside World

Runtime configuration

PreviousCode commentsNextLogging

Last updated 5 years ago

Was this helpful?

The runtime configuration should be picked up by the public interface instance - the HTTP layer in our example.

The entry point has to declare the list of configurations keys that it requires to work. The app throws an exception if any required values are missing since it won't be able to function correctly. Better to refuse to start than to throw an exception in the middle of a user journey.

Only the entry point should look at the environment; this is to ensure we define the required config keys in a single place. Picking up env vars in random places is a sure way to introduce problems that only happen when they really shouldn't (in production).

The same rule applies to the UI instances, whereas they pick up their config from environment variables, but they usually do that at build time since they are mostly static.

from the environment