Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
Feature Flags are just conditional statements but can be much more powerful. Use them so you can integrate features before they are ready to be used in production. But they have a lot more utility than just being simple toggles. Here are different ways of thinking and using feature flags.
YouTube
Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.
Configuration
In it’s simplest form, we’re really just talking about configuration. We could have some deployment process where it’s simply a matter of having a static file that’s included along side our application, that at startup reads to load the configuration file, or could even be built into it the app itself.
And of course you can take it a step further and use a external configuration store, which often allows you to load it up at startup, and even dynamically push configuration changes to you, or poll the configuration store periodly to dynamically change the configuration at runtime.
Typically you alos use this for secrets, such as API keys or even configuration strings. For example you have the configuration string for you database, which is first fetched from the external configuration store.
Once we have the connection string, we then can connect to our database.
Infrastructure
Building on that, you can use feature flags to enable technical features that aren’t necessarily functionality that’s visible to the end user.
Let’s say, for example, we have a cache but need to migrate to another instance or a totally different type of caching product/solution.
We can use our configuration store to provide us with a feature flag to specify possibly for a subset of users or tenants which cache they should start using.
This could be a simple feature toggle in our config store if the tenant uses the new cache. Using our feature flag, we are slowly migrating users or tenants from the old to the new caching infrastructure.
However, it also provides us a suitable means to roll back; if we experience issues we did not foresee, we can migrate back to the existing cache infrastructure.
In some ways, this can almost be considered A/B testing to determine which solution works best.
Feature Flags don’t have to be Toggles
I think feature flags can often be thought of as temporary. The biggest complaint I hear about feature flags is that they are used to integrate code into a production release, but they are used to make functionality available once it’s ready. Then, once it’s fully released, the feature flag is no longer necessary and needs to be deleted and removed from the code, which often doesn’t happen. And you have a wasteland of feature flags.
But feature flags aren’t always temporary. And they aren’t always just on/off toggles.
An example is a feature flag per tenant determining which 3rd Party Payment Gateway they might use.
So, the feature flag isn’t just a toggle of yes/no but rather a value from a list of options. In this example, one tenant might use Payment Gateway A, and another might have the feature flag set to Payment Gateway B.
Feature Flags are greater for allowing you to develop and integrate code without it being released to end-users until it’s ready. But they don’t just have to be used for that. Ultimately, they are configurations that you can use in many different ways. And those ways don’t have to be user-centric if a feature is visible. As my example earlier, it might be purely technical.
Join CodeOpinon!
Developer-level members of my Patreon or YouTube channel get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.