Live data from Hacker News

Ask HN: How did you build feature flags?

news.ycombinator.com

1–10 of 32 posts

Re: Ask HN: How did you build feature flags?

#2
I don't think there can be 1 fits all solution. Feature flag is at its core is nothing but a piece of your product code.

There are millions variants to implement a product, even within the same environment/infra constraints.

If you elaborate your specific goals and products - that may be a very fruitful topic.

Re: Ask HN: How did you build feature flags?

#3
Easiest way is a DB entry / Environment Variable / Config that turns a feature on and off, some central class/object that reads it and is a source of truth and a bunch of "if" statements in the right place to hide the feature and make it unavailable via APIs if turned off.

Re: Ask HN: How did you build feature flags?

#6
I'm pretty happy with our setup, though we use flags mostly for feature releases and only have a few long-lived ones.

State kept in a database table indexed on customer. One row per customer/flag name, only there when the flag is set.

We keep active flags names as constants and put into an array for easy looping in our admin ux. This makes it easy to find usage and clean them up after launch.

These are passed to the browser so the frontend can check flags, and via grpc context to any downstream services.

Re: Ask HN: How did you build feature flags?

#7
Don't build this in-house if you can help it.

I worked at an adtech company that had our own feature flag system built. Absolute pain to work with. To be fair, it had been built 6 years prior, and I worked there 4 years ago, so there were less off the shelve solutions at the time.

Switched to a company that used an off the shelve solution and it was 100x easier to work with.

Re: Ask HN: How did you build feature flags?

#10
Choosing a good solution heavily relies on whether your product is multi-tenant or not.

If multi-tenant things get complicated quite quickly. It may be worth looking into existing packages/libraries for your stack. I would be careful about using a third party service for this due to the latency it may introduce.

If not then just have a FEATURES constant. The value can be as primitive as an associative array, dict, hashmap, or struct. The keys are your flags and their values are booleans.

Not your forever choice, but very simple, quick, and easy to use.

Post reply on HN