
Ask HN: Do you use feature flags? What's the best tool for the job? - nshntarora
I&#x27;m currently evaluating tools to add feature flags to my application at work. Looking for open-source or SaaS tools you folks have used or are currently using.
======
yoz
Hi, I'm a Developer Advocate at LaunchDarkly:
[https://launchdarkly.com/](https://launchdarkly.com/)

Obviously I'd like you to use our service, but I'd rather that you find the
one that best suits your business needs. There are plenty of good open source
feature management systems out there. Just - whatever you do - don't fool
yourself into building your own. Your time's worth more than that.

If you want a deeper argument, I wrote it up here, along with some examples of
good open source systems: [https://launchdarkly.com/blog/feature-management-
platform-bu...](https://launchdarkly.com/blog/feature-management-platform-
build-or-buy/)

------
kyle-ssg
I think something to note on this as I already see this in the comments.
There's always the suggestion of "Yeah that's easy we could do that".

To this I'd say it totally depends on the usecase, I've seen 10s of tech teams
build this badly and end up causing more harm than good, some even just static
config files that require a build to change which totally defeats the point.

I think looking for an open source tool is great, to this I'd say consider the
following :

\- Before anything else, you'd definitely want the ability to turn the flags
off per environment (dev/prod etc) without having to deploy code.

\- Do you want to control who can manage features? Quite often you'd want to
enable non-tech people to manage / test features.

\- How scalable does it need to be? Some people might want to just not have to
worry about serving thousands or millions of flags.

\- Do you want to serve flags based on users or maybe even groups of users?
I've seen attempts at this but then you start having to worry about setting
traits and building some sort of rules engine.

------
TheSpiciestDev
I've worked with Split.io at a client, they had libraries for our frontend and
our backends. Their interface was also neat and would allow you to separate
out your feature flags per environment, per user or user group, or through any
other custom condition. They'd also provide statistics for A/B testing, but I
never got that far with them to try it out.

Theirs was dynamic in that you could change the rules and at a given interval
the connected user's app would refresh and react accordingly. It was pretty
complex, I suppose, but I'd roll out my own and go to something like them if I
had a lot more conditions or targets.

------
mattmanser
If you mean global feature flags, use the config file built into virtually
every single webframework and and an if statement.

It's really not complicated.

Some webframeworks require an app restart for config file changes to be
detected, or restart the app automatically when it detects changes to the
file, so I've seen people use databases. But it tends to be an
overcomplication and it's usually turned out to be a bit of a pita. It's only
worth it if you're regulalrly turning the feature on and off.

Many languages also support build flags, which strips the extra code out
completely, but it's an obscure feature, unless you write libraries, that can
confuse other programmers.

~~~
yoz
(I'm a Developer Advocate for LaunchDarkly.)

There's a huge amount of value in being able to flip a flag value and have the
app react without a restart. The most basic scenario: being able to separate
deploy from release. Deploy code with each major code change turned off;
ensure the deploy's gone well, then turn the changes on one at a time (or
whenever the feature is meant to go live). Not only does it make problem
diagnosis much easier, but it means you don't need to rollback if one of them
is buggy - just turn it off again.

But these are only feature flags in the simplest sense. Modern feature flag
systems also allow targeting rules, which allow the flag to evaluate
differently based on contextual attributes (e.g. something about the user).
They also stream these rules to a simple local rule engine within the code so
that evaluation isn't blocked on I/O. Then there's access control,
experiments, multivariate flags...

------
fullstackwife
I usually avoid using third-party FF enablement services. Maybe 5 years ago it
made more sense to use them, but as of 2020 I can't find good reasons anymore.
They don't solve the right problem. Rolling your own FF enablement solution is
cheap nowadays, it's much less hassle, much more robust, adjusted to your
needs, and it's more privacy friendly.

KISS, you most likely don't need to use an external feature flag "hadron
collider".

------
deepaksurti
Like me who didn’t know about feature flags it is described here. [1]

[1] [https://www.martinfowler.com/articles/feature-
toggles.html](https://www.martinfowler.com/articles/feature-toggles.html)

------
larsthorup
Should you use a tool at all? One code file with the flags, and a small piece
of router middleware that allows the URL to override the value of flags, and
then just if statements. This has served me well on the past 3 frontend
projects I have built.

~~~
maps7
So the URL can turn on different features?

~~~
larsthorup
Yes, using #feature:name=value. This makes it easy to share a URL to someone
who wants to test a not yet enabled feature

------
matt_s
This isn't a huge ordeal to DIY. A database table with some fields (name,
on/off, dates) and a module to call that checks the db. A simple UI/API to
CRUD those rows.

If it's a SaaS, how does your app function if the SaaS is unavailable?

~~~
shoo
I've never used a full blown whiz-bang solution for feature flags, but when I
stared at the launch darkly API one day it seemed as if:

* feature flags were generalised as certain class of functions that made an on/off decision based on certain inputs, and the definition of these functions could be sent from the server to client services that had integrated the feature flag library. Functions could be refined at runtime etc -- generalised notion of toggling a toggle.

* there appeared to be capability for services to maintain local cache of the feature flag / expression rules so it didn't introduce a hard failure point on external service. Functions uses to make toggling decisions could be evaluated with inputs locally.

Take this with several grains of salt, never used it, I might be
misremembering and it might not actually work this way

~~~
yoz
(I'm a Developer Advocate for LaunchDarkly.)

Both of these are true. See also my reply to the parent comment - you don't
even need a local cache, since all flag evaluation calls should include a
fallback value.

------
dabeeeenster
We recently open sourced our platform, Bullet Train.

[https://github.com/BulletTrainHQ](https://github.com/BulletTrainHQ)

We'd love feedback!

------
dyeje
I typically roll my own. Never had an issue. The flexibility is nice
especially if you get into very granular feature flags.

