Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: FFlags – Feature flags as code, served from the edge

fflags.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Show HN: FFlags – Feature flags as code, served from the edge

#31

Post by Sayrus »

ecshafer wrote: post #24
Sayrus wrote: post #20

Earlier quoted context omitted.

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.

That seems like code which should check customer account information, not a feature flag thats turned on or off.

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.

Re: Show HN: FFlags – Feature flags as code, served from the edge

#32

Post by tushr »

BrandoElFollito wrote: post #7
shiandow wrote: post #6

This product is probably not intended for me but at this stage I'm not even sure I know what a feature flag is any more. I thought feature flags were just toggles so you could turn features on and off. I wouldn't know how to implement those as anything other than code. Or why you would need an external service. What problem is this solving?

I had the same question after quickly reading the docs. I am probably not directly an intended user but I sure would be glad to understand what this is (as an amateur dev)

You can checkout my reply to the same comment. I have explained it in terms which is easy understand for everyone.

Re: Show HN: FFlags – Feature flags as code, served from the edge

#33

Post by ricardobeat »

ecshafer wrote: post #24
Sayrus wrote: post #20

Earlier quoted context omitted.

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.

That seems like code which should check customer account information, not a feature flag thats turned on or off.

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.

Re: Show HN: FFlags – Feature flags as code, served from the edge

#34

Post by ricardobeat »

aitchnyu wrote: post #30
ricardobeat wrote: post #11

Earlier quoted context omitted.

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) -…

Do we need a feature flag-aaS if we have a monolith and easy way to add columns to user table?

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.

Re: Show HN: FFlags – Feature flags as code, served from the edge

#35

Post by aitchnyu »

ricardobeat wrote: post #34
aitchnyu wrote: post #30

Earlier quoted context omitted.

Do we need a feature flag-aaS if we have a monolith and easy way to add columns to user table?

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.

I can see the others in the build/buy debate, but how's metric platform connected to this?

Re: Show HN: FFlags – Feature flags as code, served from the edge

#36

Post by tushr »

ricardobeat wrote: post #34
aitchnyu wrote: post #30

Earlier quoted context omitted.

Do we need a feature flag-aaS if we have a monolith and easy way to add columns to user table?

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.

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

Post reply on HN