
Ask HN: How to maintain Feature Flags for new feature releases? - raviojha
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.<p>However, at times, we might want to enable&#x2F;disable a feature in production at some instant, where we can&#x27;t afford to have any delay.<p>We thought that let&#x27;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?
======
patricioe
Hey. Disclaimer: Co-founder of [http://www.split.io](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.

------
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.

------
anthony_franco
I've never used them but I've heard that's what
[https://launchdarkly.com/](https://launchdarkly.com/) is for.

------
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.

