For Ruby on Rails there is: https://github.com/flippercloud/flipper
Ask HN: How did you build feature flags?
11–20 of 32 posts
Re: Ask HN: How did you build feature flags?
#12Don'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.
Can you elaborate on 'the pain' of using in-house feature flags?
I am genuinely curious how essentially a boolean lookup can be hard to work with.
Re: Ask HN: How did you build feature flags?
#13Redis sets or hash’s work well
Re: Ask HN: How did you build feature flags?
#14If you don't need per customer configuration just throw it all in a configuration file and call it a day.
Re: Ask HN: How did you build feature flags?
#15I work for Flagsmith these days, but formerly I was in charge of managing a lot of Trust and Safety related concerns for Clubhouse. This involved deleting a lot of records to appease regulators and creating custom features to handle stuff like CSAM and we used a lot of feature flags there to keep systems safe in case of an event.
The most important architectural decision that we made was pushing some of the feature flagging into the software layer. So, for example, every task had a module name and a task name that together would form the feature flag name. So out of the box any task could be disabled without adding further code. Combined with other good practices it went a long way. Another good option is to enable local evaluation mode[0] which allows a balance between keeping your feature flags up to date while avoiding API calls frequently.
[0] As an aside, I've worked on the implementation of local evaluation mode for one of our clients (I think Python?) at Flagsmith.
Re: Ask HN: How did you build feature flags?
#16Don'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.
Can you elaborate on 'the pain' of using in-house feature flags? I am genuinely curious how essentially a boolean lookup can be hard to work with.
You want more than a boolean flag.
You want to be able to enable features for certain customers. For example, you might want to roll out a feature to only the US or only English speaking users because you haven't internationalized it yet. Or you might want to enable it for select customers. Or all sorts of other examples.
You may also want the ability to gradually roll out a new feature over time. This lets you test in small scale and also lets you ramp up load on new backend services.
You can also schedule features to be released in advance. This helps you align releases with things like marketing or customer service training.
I only hit on a few points, but you can see it's a lot more than boolean flags.
Re: Ask HN: How did you build feature flags?
#17We at https://flipt.io are putting on a buy vs build webinar in a couple of weeks to discuss this very thing as it's a common question that engineering teams seem to have.
If you're interested in attending its taking place on LinkedIn on April 17: https://www.linkedin.com/events/buildvs-buy-pickingafeaturef...
Re: Ask HN: How did you build feature flags?
#18Earlier quoted context omitted.
Can you elaborate on 'the pain' of using in-house feature flags? I am genuinely curious how essentially a boolean lookup can be hard to work with.
You want more than a boolean flag. You want to be able to enable features for certain customers. For example, you might want to roll out a feature to only the US or only English speaking users because you haven't internationalized it yet. Or you might want to enable it for select customers. Or all sorts of other examples. You may also want the ability to gradually roll out a new feature over time. This lets you test…
Possible to have a feature requiring a dependency update that may be mutually exclusive with the previous dependency graph of the former feature set?
Re: Ask HN: How did you build feature flags?
#19Choosing 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, ha…
Ah we're multi-tenant. In what ways do you feel like it gets complicated quickly?
Re: Ask HN: How did you build feature flags?
#20[dead]