Config variables should never be embedded directly in the codebase. It is a common practice to extract them into a separate configuration layer. A standard approach for Ruby on Rails apps is to use static
ENV variables that can only be changed via a release process. In this blog post, I’ll describe the use cases for using dynamic config variables that can be modified on the fly. I’ll also share a simple way to start using them in your app without including additional gem dependencies.
Dynamic vs. static configuration
It is perfectly OK to use static
ENV variables for storing values that are not likely to change, i.e., database connection URL, API keys, etc. For the development environment, I recommend direnv or dotenv for managing local variables configuration. Tooling in the production environment is different depending on the stack. But, it usually has a form of static YAML files that are parsed during a deployment process.
However, while conducting my Rails performance audits, I’ve found static configuration limiting in some cases. Achieving the optimal performance often consists of tweaking various dials and buttons. When applying a change to a bottleneck endpoint is often impossible to know which value will work the best before testing it with actual production traffic patterns.
A few examples of values that could require dynamic tweaking are:
- cache refresh time thresholds
- throttling limits for Sidekiq jobs
- collections pagination config
- feature flags
Deploying a change to a static
ENV variable might take over a dozen minutes, depending on a project’s release mechanism. Often you need to wait for an elaborate continuous integration process to tweak a single value. Misconfiguring a variable in a bottleneck endpoint might result in a prolonged degraded performance or even a downtime before the new release goes live.
Read on to learn how you can dynamically change configuration variables without a need for a sluggish release.
Redis as storage for dynamic config variables
I’ve found Redis to be an optimal tool for storing dynamic config. Reading data has virtually no overhead, it does not require cumbersome schema migrations, and 99% of Rails projects out there already have it in their stack.
Let’s have a look at a service object that you can use to read and write config variables:
Since, these are global values we’ll leverage the built-in
Singleton module. The
set methods offer a lightweight abstraction over the Redis API. We add keyname prefixes for easier debugging and fallback to
ENV values. We also utilize
Marshal methods to serialize values to strings.
You can use this service object like that:
Practical examples of using dynamic config values
Let’s now see our service object in action. When working with dynamic variables, you need to be careful to use them well in a dynamic way. It’s easy to accidentally freeze the value of a dynamic config if you use it incorrectly.
Let’s consider a sample controller where you want to configure size of a paginated collection using a static variable:
If we want to dynamically control the size of a returned collection we can use the following implementation:
Please notice that you have to read the value of a dynamic variable inside the index action. If you saved it to a constant like in the former example, then changing the value wouldn’t have any effect without an additional release.
Dynamic config variables can be extremely useful for tweaking details of your project with an instant feedback loop. They incur a small complexity overhead. In return, this technique allows you to deploy changes with more confidence that errors can be quickly reverted without impacting your users.