This post has been sitting in my drafts for months, so I'm shoving it out into the world!
Garrett Dimon and I have been chatting back & forth about Rails configurations. This is an extension/riff on his idea for Unified Configuration in Rails
While Garrett's approach hooks nicely into Rails and has multiple metaprogramming niceties; my approach is generalized & direct (but verbose). Essentially: create a
Configuration class that is a PORO; I named mine
AppSettings. You can see a gist of it here!
This is born out of a convention in my iOS apps, which use a Swift struct called
Configuration, that pulls the configuration from various sources into a strongly-typed, consistent location that is easy to remember.
My primary focus is to explicitly declare the configuration values and standardize how they’re accessed with a straightforward API, rather than try to standardize how they’re stored. This is because there are so many cases where either:
- “It depends” on how they should be stored.
- There’s an external dependency that makes you use a particular storage mechanism.
- The configuration is so entrenched as part of the environment that it ends up in the environment’s configuration.
Using a PORO with clearly defined methods gives you:
- Clarity in how the value is retrieved.
- The flexibility for different value types. Some are single keys, some are nested objects, etc.
- The same API for dynamically generated values; such as subdomained URIs
- An easy object to mock out for tests as needed.
I've been using this approach for an internal app I've been commissioned to make; it's worked out very well so far! I'd definitely recommend moving towards this approach in your projects.