The feature flags

Imagine launching a new feature to your entire user base, only to discover a critical bug that brings your application to a halt. The frantic rollback, the lost trust, the late-night fixes – it's a developer's nightmare. But what if there was a way to deploy new code confidently, test features in production with a small segment of users, or even turn features on and off at will, without redeploying your application?

Enter Feature Flags (also known as Feature Toggles or Feature Switches). In this post, we'll dive deep into what feature flags are, how they work, and how you can leverage them to build more resilient, user-centric web applications. Get ready to transform your deployment strategy!

The way the feature flag works is just be returning true or false and based on this condition your code will show new UI or the older UI.

That means you need to have the older + new logic in the code. Something like below:

const featureFlagClient = initFeatureFlagsClient();

const newUIEnabled = await featureFlagClient.get(
  "new-feature",
  false, // default fallback
  {
     context: { 
          //Any user details for which you want to pass to determine the 
     }
  }
);

if (newUIEnabled) {
  renderNewUI();
} else {
  renderOldUI();
}

So now, you have a ON/OFF switch to control the visibility of new UI. Even after it was deployed, it won't be available to anyone. Once you set the flag to true, then only the users will be able to see the shiny new UI that you just created.

Pros of using feature flags:

• ON/OFF switch: You can just control the flow without the deployments and it also gives you a configuration you can change anytime
• Safety Net: You can roll a new feature incrementally and rollback instantly that gives you a safety net if something goes wrong.
• Beta Access: This enables you to roll feature for a certain individuals who signed up for using new UI in BETA mode.
• No Deployments: If you want to enable or disable this new UI, you don't need to deploy the new build or revert any commit. All clean and good.

But not everything that shine is gold, if you use feature flags without giving it a much thought, you will find yourself in a technical debt very fast.

Things you should consider before

• Complexity * Complexity: Yes, if you use feature flags blindly and think of it as one solution for most of the problems, you are adding a very thick layer of complexity in your codebase. Now, you have to maintain both the old and new features, as both can be used and anytime and nobody knows which ones are using in which cases.
• Nested complexity: What if you used a feature flag inside of old and new UI features that are already under one feature flag. You are basically adding a complex nested flag based structure that won't go far enough.
• Technical Debt: If you use feature flags for a deployment and never removed the feature flag after the users are successfully migrated to the new UI, then it will become a debt that either needs to paid and the more flags you have, the more interest that debt collects.

So, feature flags are a great way to roll out/test features on production without making them available for public, but only if you know what you are doing and you do it the right way.

Things to consider

While making the decision whether to implement feature flags or not, keep these things in your mind:

• Ask if you really need it: Ask yourself whether you really really need the feature flag? If yes, keep reading: else exit;
• Clean the clutter: If you are implementing a feature flag, make sure to assign a task to remove this feature flag if not needed afterward.
• Document the requirement: And keep it documented, what is the need for this flag, the scope of this flag, when it introduced.

As we wrap up our exploration of feature flags, it's clear they are far more than just a temporary switch. They represent a fundamental shift in how we approach software development and deployment. By embracing feature flags, you're not just gaining the ability to turn features on and off; you are also reducing the stress and risk associated with every new release.

Implementing feature flags effectively requires careful planning and clear communication within your team. But the benefits—faster innovation, happier users, and more confident deployments—are well worth the effort.

So, next time you're planning a new feature, consider the power of the flag. It might just be the most impactful decision you make for your web application's future.

I hope this blog post made you learn something new or just pressed F5 on your knowledge system. Thanks for reading.

Umang Mittal signing off!