Using Feature Flags for Auth0 Requests

When building DevCycle we were facing an issue where we had two different backends. We had one that was handling interactions with Auth0 and we wanted to move those calls from one backend to another.

In order to move quickly during early development, we were communicating directly between our NextJS backend and Auth0, but the time eventually came that we needed to move these interactions into our API service to reduce duplication and increase the consistency of our authentication and permissions models.

The main reason we did this is to implement our authentication and permissions model more consistently along with keeping our backend logic in one central location rather than having it split in two. In turn, this allows us to iterate on features faster and reduces the number of API services we need to worry about.

We didn’t want DevCycle users to notice any changes or experience any service disruptions, so we used feature flags. This allowed us to deploy and test a major change and validate that it was working by selectively targeting that change to the people testing it.

We leveraged feature flags to support calls from both backends during the transition. We decided to flag at the point we were making the request. This way we could have flags that call to both backends and set it to just our team to test in development and staging before turning it on for everyone once we were confident it was working. The final step was to remove all the feature flags so only the newer versions are used.

The process of removing feature flags is incredibly simple. All we need to do is look for where we’ve referenced feature flags and pull out the branch of code we’re no longer using. We’ll end off by updating tests to ensure that they don’t rely on branches that are no longer active.

‍

How we would have done the transition without feature flags

If we didn’t use feature flags for this transition we would try to deploy front and back end changes simultaneously. The issue with this is that nothing is truly simultaneous so there would always be an overlap period where the front end would be expecting the old APIs.

While there are a few ways to make this transition without feature flags most of them involve exposing new work to end-users before it’s fully tested making the opportunity to see bugs or errors far higher. Another benefit of using feature flags is that we could deploy changes piece by piece as they were working.

In the past, this process would take a lot of work in our dev environment. We wouldn’t make any releases to customers until we finished everything, which slowed down the pace of releasing changes to customers. Making big releases also means there’s a higher chance of unexpected problems. Using feature flags allowed us to release small changes consistently so every time something went wrong we could easily track it down.

Using feature flags also meant that this project took as long as we expected it to without any surprise bugs or major errors that needed to be fixed which would push back our timeline. It minimized the changes of anything unexpected happening which could have made the project take far longer. It also gave us peace of mind since we were able to walk through isolated areas. We didn’t have the additional stress of taking down the tool or that customers would see issues. 

In the past, we had a similar effort where we didn’t use feature flags which didn’t work when we rolled it out. Unfortunately, our only options were to either fix it or fully roll it back and lose our changes. When we used feature flags if there were any issues we just turned it off. From there we could go in and look for the issue, fix it and turn it back on once the problem was resolved.

Rolling back to a previous commit is hectic but being able to isolate the issue saves a lot of time and confusion.

Why isn’t everyone using feature flags?

When you’re trying to move as fast as possible, it’s common to leave things to the side that are not immediately relevant to what they’re working on. It takes a little bit of work upfront to create and maintain two separate branches of code but it allows for more consistency and a lot less risk down the line. Several teams don’t weigh risk heavily enough and feature flags are the ultimate tool for risk mitigation, especially in the long term.

The setup and cleanup needed are other reasons people are against using them. However, the issues you’re avoiding by using feature flags are worth it.

Tips for starting to use feature flags

When starting to use feature flags it’s important to pick the right feature to start. For your first feature flag, you want to avoid situations where you would need to flag in several different locations. Try to focus on an isolated area of your code. An example would be replacing an old component with a new one. This allows you to figure out the workflow of using feature flags.

The best use case for feature flags is change failure. When you’re pushing to production and it doesn't get deployed properly even though it passed all the tests. Rather than having it break anything, you can just use a feature flag to disable it. From there if something breaks you can have it visible to just yourself to solve the issue. Being able to separate deployment from release creates a buffer of safety.

Get started with DevCycle

DevCycle is the developer’s choice for feature flags that are easy to set up and manage. Mitigate risk, increase your deployment cadences and gain peace of mind. Get started with a 14-day free trial of DevCycle.