In software development, there are times when you don't want certain parts of the application to be available for the user. To achieve this, we can use feature flags. In my career, I have come across two types of feature flags: those that are set at build time and those that are set at run time.
1. Build Time Feature Flags
Build time feature flags are usually used in combination with trunk-based development to avoid creating a long-lived branch for the feature. Instead, the functionality is hidden behind a flag.
Application Level Configuration
You can configure what and when is available by defining the feature flags inside a configuration file and leverage that to know when the feature is on or off. If you want the feature to be available only in certain environments, you can define it inside an environment file and update the value for each environment.
Pipeline Level Configuration
To avoid making commits each time you want to toggle a feature, you can leverage the power of CI/CD and create parameters for the feature flags inside the platform. These can later be replaced with actual values when the application is building.
At some point, though, the build of the application can take quite some time. If you want to toggle a feature faster, there is another way.
2. Run Time Feature Flags
Run time feature flags, as the name implies, are a good way to toggle features while the application is running. There are two implementations that I have come across.
Application Level Configuration
These types of flags can be configured at the application level as well. However, their value can change based on different factors depending on the implementation. You can have a path or a query param that only certain users know and can use to access the feature. This type of implementation would require commits and rebuilding if we want to make a feature available or not by default.
Service Level Configuration
A better way to implement run time feature flags would be by using a service. There are out-of-the-box solutions that you can use and integrate into your application, but you can also develop one from scratch. The service would be consumed by the application to check the state of the flags and, ideally, by another application that would make the configuration of those flags easier.
Conclusions
Build time feature flags are powerful, by using them, you can make sure the user doesn't have access to the parts of the application that are hidden behind them. They are very useful if you don't want certain code to be available in your application.
Run time feature flags are great to use when a feature is already developed, as the code for it will always be in the application. If the service implementation is in place, to make sure parts of the feature are not accessible by mistake, the feature flag service should be consumed by related components or services as well.