HN Explorer

Ask HN: How to maintain Feature Flags for new feature releases?

14 points by raviojha ↗ HN
We store all feature flags as constants in the repository itself. Recently, our CI has become quite slow because we added a lot of tests. So it takes bit of a time to reflect the changes in production.

However, at times, we might want to enable/disable a feature in production at some instant, where we can't afford to have any delay.

We thought that let's move all of them to database. It would solve the problem at hand, however, it would also result in extra network call. So how do you accomplish this?

4 comments

[ 0.21 ms ] story [ 18.2 ms ] thread
awjr
I'm going to make an assumption, if the application uses a database, then there is absolutely nothing wrong with that approach. This plays well into security models as well enabling you to 'allow' certain users access to features.
WorldMaker
An extra network call may not be a problem. The question is your own application's performance and how and how often your feature flags are checked. You'll have to try a spike and figure out what your own performance needs may be.

Optimizing that is like optimizing any other database/network calls: find a caching strategy that makes sense for your application; avoid checks where you already know the answer or the answer doesn't matter anymore; find ways to bulk retrieve/cache a bunch of checks at the same time instead of one-at-a-time; etc.

patricioe
Hey. Disclaimer: Co-founder of http://www.split.io here.

We built libraries like this before at previous jobs and now created Split to solve these type of problems and more. I can share some insights below of things we ran into while developing such libraries.

Libraries should be optimized to avoid network calls as much as possible. Using local or external caches like Redis, CDNs, etc, and leveraging protocols like HTTP Cache are the corner stones to achieving the behavior you are asking about. Moreover, you can use things like Server-Sent events and websockets to make your system react in near-realtime when flags are changed. Although this last approach leads to a little bit more complicated architecture.

Other things you didn't mention but worth considering whatever your decision is, are:

- How to manage old unused flags (tech debt). Processes are great but even better when enforced by tools. Often times people use task tracking tools to set reminders to themselves to remove a flag after X amount of days.

- How to integrate that data collected to power things like A/B testing to augment your business decisions.

- How to integrate your library with testing frameworks?

Happy to chat more about other topics we encountered while using flags.