API with NestJS #71. Introduction to feature flags

JavaScript NestJS

This entry is part 71 of 77 in the API with NestJS

With feature flags (also referred to as feature toggles), we can modify our application’s behavior without changing the code. In this article, we explain the purpose of feature flags. We also show how to implement them ourselves and discuss the pros and cons.

You can find the code from this article in this repository.

The idea behind feature flags

Thanks to feature flags, we can switch a certain functionality on and off during runtime without the need to deploy any new code.

A feature flag, at its core, is a boolean value that we can toggle and use in if statements.

Benefits of feature flags

One of the main benefits of feature flags is that merging our changes into the master branch does not necessarily mean delivering the new feature to our users. Therefore, we get a lot of control over our application.

For example, feature flags are part of the Trunk Based Development practice, where we merge our code to the master branch very often. Since merging does not mean exposing the new feature to the users, we can merge features we haven’t finished. Thanks to that, the new feature can undergo the code review process in chunks instead of dumping a lot of code in a single pull request. The above can make it significantly easier for our teammates to review our new code.

Also, feature flags can help us minimize risks associated with deployments. If the QA team notices that the latest changes don’t work as expected in the production environment, reverting them is as easy as switching the toggle. Besides the QA team, we can also notice the issue through a monitoring system we have in place. A good example would be a sudden spike in the response time of some endpoints in our API.

Besides the above, we could build a more sophisticated feature flags system or use a third-party tool with functionalities like A/B testing. With that, we can present two versions of our application to users and determine which one they like the most.

Drawbacks of feature flags

While feature flags can benefit our application, they are not a perfect solution. They add complexity to our code that can make it harder to understand. But, what’s even worse, they create a lot of various versions of our application that, ideally, should be tested separately. For example, if we have five feature flags, it gives us 32 possible combinations.

There are two possible values for each of the five feature flags, and 25 equals 32. This would be even more complicated if we would have feature flags that can have values other than booleans.

Until we test each of them separately, we can’t be entirely sure if not a single one of the combinations has an unexpected side effect. Five feature flags might seem like not a lot, but manually testing 32 separate versions of our application is probably unrealistic. It would be reasonable only to verify the combinations we expect to happen in production, but that requires that we understand the project and the business domain very well. The more flags we have, the more difficult it is to verify.

Because of that, feature flags need to be short-lived. Although it is easy to add a feature flag, it can cause us more and more effort to maintain it the longer we keep it. Therefore, we should retire the feature flag once we know that a particular feature works correctly.

Having feature flags can encourage us to merge features that are not yet finished because they are hidden behind a feature flag. We need to be very careful, though, because there is a chance that a feature might leak out by accident if not encapsulated correctly. Having to test that adds even more complexity to testing.

Implementing feature flags with NestJS

We probably want different values for feature flags in different environments, for example, in staging and production. We would also like to change the feature flags without modifying the codebase and deploying.

The most straightforward way of doing the above is storing our feature flags in a database. First, let’s define an entity for our feature flag.

featureFlag.entity.ts

If you want to know more about identity columns, check out Serial type versus identity columns in PostgreSQL and TypeORM

Adding, modifying, and removing feature flags is relatively straightforward. We can fit all of it into a simple service.

featureFlags.service.ts

The above service is a good candidate for caching. If you want to know how to do it, check out API with NestJS #23. Implementing in-memory cache to increase the performance and API with NestJS #24. Cache with Redis. Running the app in a Node.js cluster

Besides creating a service, we can also define a controller that allows us to manage feature flags through the REST API.

featureFlags.controller.ts

It might be a good idea to develop a designated frontend application that uses the above API so that it is easy to use.

Checking the feature flags

The most straightforward way to check if a feature flag is enabled is using our directly.

authentication.controller.ts

The above approach might be fine if our feature is small and straightforward. But unfortunately, it could be challenging to track where we’ve used the method. So a better approach might be to use the in the .

emailConfirmation.service.ts

Disabling API endpoints

Besides affecting services, we might want to disable an API endpoint defined in a controller.

emailConfirmation.controller.ts

Unfortunately, the above logic can get quite repetitive. To deal with this, we can create a guard using the mixin pattern.

featureFlag.guard.ts

If you want to know more about mixins, check out API with NestJS #57. Composing classes with the mixin pattern

Now, the above guard is very straightforward and makes our code clean and simple.

emailConfirmation.controller.ts

Summary

In this article, we’ve gone through the feature flags and their benefits and drawbacks. While they might help us with the process of reviewing and deploying our code, we need to be aware that they might make testing more complicated. Also, we should remove the flags we don’t need anymore.

Besides the above, we’ve also implemented a mechanism for managing feature flags using a PostgreSQL database. While doing so, we’ve used the feature flags directly through a service and a guard. There is still more to feature flags, such as A/B testing, but this is a topic for a separate article, so stay tuned!

Series Navigation<< API with NestJS #70. Defining dynamic modulesAPI with NestJS #72. Working with PostgreSQL using raw SQL queries >>
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments