Blog

Problem statement

While you are working on a new feature in your project, sometimes you have to “hide” that feature and provide an access to the feature only if some conditions are met. Also, sometimes you are refactoring some complex functionality and you want to have a mechanism to switch between old (proven) and new (refactored) functionality. Or you just want to switch between two different implementations for data fetching or storing.

In all these scenarios, you can use feature flags to control an access to specific functionality and to switch between several possible implementations.

Feature flag solution

Feature flags (or feature toggles, flippers, switches controls etc.) are techniques for modifying system behavior without actually changing the code.

Requirements

Our requirements were:

• to group feature flags per application and to restrict access to specific applications,
• to have a meta-information about owner for every feature flag,
• to support more complex logic (like date/time-based conditions), not only simple On/Off logic,
• to have lightweight service,
• to support Google SSO for user login,
• to support auditing, and
• to have SDKs for Python and JavaScript.

Third party options – past and present

In the past, we were using Contentful and Redis for feature flag storage. Contentful provides a nice and intuitive UI for dynamic feature flag updates by any team member, while feature flags stored in Redis were updated statically through pull requests by developers. With this setup, we did not have an easy way to track changes on feature flags, we did not know who is the feature flag owner or creator, which application is using a specific feature flag, nor if the feature flag is still in use. Along with this, we have all our feature flags defined in two separate locations.

We decided to introduce a new service in our environment which will be used for feature flag manipulation.

First of all, we did some research and we tried to find an open-source/paid third-party library or project which will be good-enough-fit for our requirements. During that time, we analyzed Flagsmith, FeatureHub, Unleash and GrowthBook. Each of them have hosted demo applications publicly available for testing purposes. Also, they provide excellent documentation for self-hosting solutions.

After analysis, we realized that all of them provide front-ends and SDKs (for Python and JavaScript, at least) and an out-of-the-box solution for feature flag management. Moreover, they support SSO and auditing (in paid flavor, mostly). But, to be honest, neither one satisfies all our needs: there were some features which we did not need and there were not a few features which we needed.

So, we decided that we will implement our in-house solution for feature flags.

Decision to go in-house

After initial analysis we concluded that neither one solution satisfies our needs completely and that we will be able to implement our own (MVP) solution in a few weeks.

We decided to use the PostgreSQL database for feature flag storage and the FastAPI framework for the Python back-end. Also, we wanted to create simple SDKs for Python and JavaScript. For initial increment, we decided to skip front-end development.

In-house development experience

Our solution has a few key components:

• User component: for user management
• Application component: for managing applications which will consume feature flags
• Permission component: for permission resolving (we had to know which user can modify feature flags for specific application)
• AuditLog component: for insights into updates in our system
• FeatureFlag component: for feature flag management

We estimated and actually implemented an MVP version for our in-house feature flag solution in two weeks. Beside that, we implemented only features that we really needed, without introducing additional complexity into our system.

Conclusion

There are a lot of ready-made solutions for almost everything that you need. But sometimes all these solutions do not satisfy all your needs completely: most of the solutions are general-purpose solutions created for the brother audience, which can be more complex and cover more features than you actually need. Sometimes it is better to implement your own solution and cover all features that you really need. On the other hand, during our research phase we acquire a lot of domain knowledge which was tremendously useful during our planning and development sessions.