Why you should use feature flags in your front-end application

Why you should use feature flags in your front-end application

Feature flags are a software development process that allows you to enable or disable features in your application without modifying code or performing a deployment. In this article, we’ll discuss eight reasons why you should be using feature flags in your front-end application.

1) As a kill switch

A new feature can always have unexpected complications that you only notice once it’s live in production. When you realize that something has gone wrong, you should disable the feature as fast as possible to stop negatively impacting your users.

Traditionally this would require modifying code and deploying it. This has several downsides:

  • It requires the relevant developers to be available, which isn’t always the case when something goes wrong.
  • It takes time to modify and deploy code. Even a simple rollback takes time and introduces an additional risk of something going wrong.
  • Rolling back a deployment will remove all of the features and functionality in the deploy, not just the one feature that needs to be removed.
  • Rolling back a deployment is more complicated if there have been additional deployments afterward.

If you’re using feature flags, you can quickly disable the problematic feature with just a few clicks. Anyone on your team can modify the feature flag, making it easier and faster to resolve the problem.

Additionally, using feature flags will make it easier to diagnose and fix the problem. You can enable the feature in your non-production environments for testing. You can also enable the feature in production just for yourself to test in production without negatively impacting your users.

If something goes wrong with a new feature, you’ll be happy that you can use a feature flag as a kill switch instead of scrambling to fix the problem with a code change and deploy.

2) Remove deploy-order dependencies involving back-end changes

Changes in your front-end often require corresponding changes on the back-end. This results in a forced deploy order, where you must deploy the back-end code before you can deploy the front-end code. This is called a "deploy-order dependency."

Deploy-order dependencies are annoying for development teams of any size but can introduce a lot of complexity for larger teams and often require coordinating between multiple developers or even multiple teams.

By putting the front-end change behind a feature flag, you can deploy the front-end before the back-end. This removes the deploy order dependency and reduces the need for coordination.

Using feature flags is also beneficial in the case of rollbacks. If you need to roll back a back-end change, you must also roll back any dependent front-end changes. If you are using feature flags, you can simply disable the front-end feature until you deploy the back-end change again.

3) Deploy change consistently across multiple front-end applications

As applications become more complex, it is good practice to break large applications into many sub-applications. For example, a product could have three separate front-end applications: one for authentication, one for billing, and one for the core product functionality.

If you split your product well, user experiences should rarely span multiple applications, but it is sometimes unavoidable. When this happens, you find yourself in the situation of needing to deploy multiple front-end applications to deploy the change.

Needing to deploy multiple applications causes two main problems:

  1. You need to deploy the group of front-end applications together. On larger projects, this can complicate planning and require multiple developers to coordinate.
  2. When you’ve partially deployed the group of applications, there will be an inconsistent user experience across the overall product.

You can eliminate this problem by putting the changes in each application behind feature flags. You can now deploy the applications in any order and at any time. Once you have deployed all of the applications, the feature flag can be enabled, and the new functionality will consistently change across applications.

The use of feature flags also makes rollbacks easier. Without feature flags, if you need to roll back one application, you must roll back the others to keep a consistent user experience. With feature flags, you can simply disable the feature flag and roll back the single application needed.

4) Safely test features in production

Deploying new functionality is often unpredictable and risky, especially when it involves new infrastructure or configuration changes. We do our best to test in staging environments, but that usually doesn’t fully replicate the realities and complexities of our production environments and production data.

Additionally, there are times when we can only test in production, such as introducing new infrastructure or making a configuration change to the production environment. These situations are exceptionally nerve-wracking. I’m sure most of us have had the experience of deploying something to production and then feverishly testing to make sure nothing has broken.

We can reduce this risk by releasing the front-end portion of a new feature disabled behind a feature flag. With the new feature disabled, you don’t need to worry about it impacting your users. Once deployed, you can manually enable the feature for just yourself and ensure everything is functioning as expected. Once you feel confident the new feature is working, you can enable the feature for your users.

5) Gradually roll out a new feature to slowly add load to your back-end

Front-end functionality often relies on back-end infrastructure, either your own back-end or third-party services. By releasing a feature to all your users at once, you immediately start placing 100% load on the back-end.

Unlike front-end code, the back-end is a shared resource among all your users, which means it can be overloaded with too many requests or poorly performing code. If overloaded, your back-end could slow down or fail entirely.

There are some things you can’t fully predict until sending production traffic to your back-end:

  • Can your back-end handle production load?
  • Are there limits that your backend will hit under load? These limits can be things like firewalls, third-party APIs, database connection pools, etc.
  • Does the back-end have a performance problem that only shows up under production load or with production data?

Rather than risk overloading your back-end with a new feature, you can use a feature flag to gradually enable a new feature for a percentage of your users. For example, you can enable a new feature for 10% of your users, monitor back-end performance, and then enable the feature for 25%, then 50%, and then 100% of your users as you feel confident that your back-end can handle the load.

6) Deploy a feature now and enable it later

There is often more to launching a new feature than deploying application code. There are other tasks like informing your customer service team, updating your knowledge base, product change notifications, etc.

Developers generally want to deploy code as soon as possible once it's tested to avoid blocking other deploys or creating merge conflicts with future changes. This is usually at odds with other parts of your business that desire a planned future date for when a new feature will get launched.

You can meet both needs by putting new features behind feature flags. This allows you to deploy whenever it is convenient while leaving the feature disabled until the planned launch date.

While this may seem like it only applies to larger companies, a small team or solo developer may often want to wait to enable new functionality until the start of the workday so that they can be available after the feature is released to monitor for problems.

7) Enable features only in specific environments

Sometimes there are features that you only want to enable in specific environments. For example, you might want to only enable a third-party integration or third-party service in production.

Often this is done with code like if(process.env === ‘production’) which is simple to implement, but requires a code change to enable the feature in development or staging environments. While a seemingly minor annoyance, changes like this have to be committed, reverted, and re-tested before being deployed to production. Using a feature flag to enable or disable features in your different environments is more convenient and less error-prone.

8) Configure features with feature flag data payloads

Feature flags are more than just enabled/disabled toggles. They can also carry data payloads like numbers, strings, or even structured JSON data.

You can use data payloads to update your app without deploying new code. For example, you could use a payload to configure prices in your product or to set the text for an in-app notification.

This is especially useful when a configuration is depended on by multiple applications. Without feature flags, you would need to update and deploy multiple applications. With feature flags, you only have to modify the feature flag payload and the change will take effect in all applications. Using real-time feature flags will ensure your apps update at the same time to keep a consistent user experience.

Conclusion

As shown in these examples, there are a lot of reasons to use feature flags in your front-end applications. They can help speed up your development process, reduce deploy risk, and enable application changes without deploys.

If you are interested in trying feature flags in your front-end application, you can sign up for AppFlags for free.