Introduction to feature flags
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…
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.async register(@Body() registrationData: RegisterDto) { const user = await this.authenticationService.register(registrationData); const isEmailConfirmationEnabled = await this.featureFlagsService.isEnabled('email-confirmation'); if (isEmailConfirmationEnabled) { await this.emailConfirmationService.sendVerificationLink( registrationData.email, ); } return user; }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 import { Column, Entity, PrimaryGeneratedColumn } from 'typeorm'; @Entity() class FeatureFlag { @PrimaryGeneratedColumn('identity', { generatedIdentity: 'ALWAYS', }) id: number; @Column({ unique: true }) name: string; @Column() isEnabled: boolean; } export default FeatureFlag; 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 import { HttpException, HttpStatus, Injectable, NotFoundException, } from '@nestjs/common'; import FeatureFlag from './featureFlag.entity'; import { InjectRepository } from '@nestjs/typeorm'; import { Repository } from 'typeorm'; import CreateFeatureFlagDto from './dto/createFeatureFlag.dto'; import UpdateFeatureFlagDto from './dto/updateFeatureFlag.dto'; import PostgresErrorCode from '../database/postgresErrorCode.enum'; @Injectable() export default class FeatureFlagsService { constructor( @InjectRepository(FeatureFlag) private featureFlagsRepository: Repository