News for hackers. Stuff that matters.

A comment on Show HN: FFlags – Feature flags as code, served from the edge. Parent comment

Re:Show HN: FFlags – Feature flags as code, served from the ... by ricardobeat on Wednesday August 06, 2025 @06:38AM (#44810256)
Writing your own logic to handle flags is trivial at first, especially if you're running a monolithic app, but quickly grows in complexity:

- distributing flags to multiple services

- broadcasting updates

- caching rules

- audit logs

- product, not eng, will start managing the flags at some point and needs easy access

- custom logic for gradual rollouts, A/B testing

- custom attributes support (used in evaluation)

- managing multi-variant flags

- supporting multiple platforms (backend, frontend, native apps, services, jobs) and evaluation strategies (eager server-side evaluation vs shipping a client-side engine)

There are quite a few open-source options like Growthbook, Flagsmith, go-feature-flag, and Unleash that you can check out for comparison.

[ Parent | on HN ]
Re:Show HN: FFlags – Feature flags as code, served from the ... by tantalor on Wednesday August 06, 2025 @08:56AM (#44811339)
> product, not eng, will start managing the flags at some point and needs easy access

How to tell you have a broken engineering culture.

[ Parent | on HN ]
Re:Show HN: FFlags – Feature flags as code, served from the ... by Sayrus on Wednesday August 06, 2025 @09:02AM (#44811396)
Some flags are meant to be enabled for specific customers, on-demand, depending on what type of contract is signed, under NDA and so on. Over time, many department that aren't "engineering" need to be able to change some flags. That doesn't imply your culture is broken.
[ Parent | on HN ]
Re:Show HN: FFlags – Feature flags as code, served from the ... by ccakes on Wednesday August 06, 2025 @09:10AM (#44811495)
I think most would say that’s configuration, not feature flags. The differences can be subtle but I at least don’t think they’re the same thing
[ Parent | on HN ]
Re:Show HN: FFlags – Feature flags as code, served from the ... by ecshafer on Wednesday August 06, 2025 @09:35AM (#44811812)
That seems like code which should check customer account information, not a feature flag thats turned on or off.
[ Parent | on HN ]
Re:Show HN: FFlags – Feature flags as code, served from the ... by Sayrus on Wednesday August 06, 2025 @12:39PM (#44814342)
Activating only for beta users or opted-in users is a supported use-case on OpenFeature using the dynamic context (https://openfeature.dev/specification/glossary#dynamic-conte...).

If your goal is to end up with the flag enabled on all requests, the only difference is the rollout strategy. You can prioritize accounts, manually enable things with one customer that you know likes to test your alpha features, and so on.

[ Parent | on HN ]
Re:Show HN: FFlags – Feature flags as code, served from the ... by ricardobeat on Thursday August 07, 2025 @04:56AM (#44822211)
Flags at this level are not simple toggles, they will embed some business logic - that's the custom logic and attributes that I mentioned. This is standard fare in Statsig, Split, Launchdarkly, and most other commercial providers. You then collect metrics for each group to monitor features.

You use these to manage gradual rollouts, or phased rollouts by customer segments, and to run A/B tests on smaller cohorts.

[ Parent | on HN ]
Re:Show HN: FFlags – Feature flags as code, served from the ... by boxed on Wednesday August 06, 2025 @09:14AM (#44811534)
Sounds like most of those problems are just problems with microservices generally. Adding a service makes this worse.
[ Parent | on HN ]
Re:Show HN: FFlags – Feature flags as code, served from the ... by tushr on Wednesday August 06, 2025 @10:24AM (#44812454)
> product, not eng, will start managing the flags at some point and needs easy access

That's the typical pattern and why most tools focus on non-technical UIs. FFlags targets a different niche. Teams where developers want to maintain control over flag logic.

[ Parent | on HN ]
Re:Show HN: FFlags – Feature flags as code, served from the ... by aitchnyu on Wednesday August 06, 2025 @11:26AM (#44813299)
Do we need a feature flag-aaS if we have a monolith and easy way to add columns to user table?
[ Parent | on HN ]
Re:Show HN: FFlags – Feature flags as code, served from the ... by ricardobeat on Thursday August 07, 2025 @05:01AM (#44822233)
If you're not running A/B tests, doing gradual rollouts, don't have a metrics platform, and haven't had to go beyond simple on/off status, probably not.
[ Parent | on HN ]
Re:Show HN: FFlags – Feature flags as code, served from the ... by aitchnyu on Thursday August 07, 2025 @08:54AM (#44823866)
I can see the others in the build/buy debate, but how's metric platform connected to this?
[ Parent | on HN ]
Re:Show HN: FFlags – Feature flags as code, served from the ... by tushr on Thursday August 07, 2025 @09:18AM (#44824106)
I have a bias but I would still suggest using feature flags even for on/off functions. Example of how I do it:

https://x.com/ctushr/status/1949215574980272177

[ Parent | on HN ]