As someone who’s been thinking about feature toggles and continuous delivery often lately, OpenFeature has been helpful.
Kudos to the team!
OpenFeature – a vendor-agnostic, community-driven API for feature flagging
11–20 of 67 posts
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#12I don’t get it. Why is this needed above and beyond the standard ways of configuring deployed services?
Do you mean feature flags? This enable you to change the configuration at the runtime. Ex: A/B Testing and changing a behavior for a subset of users, disable feature when you want it (particularly useful when you are in Trunk Based Development and don't want to deploy a beta feature to everyone for example).
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#13I don’t get it. Why is this needed above and beyond the standard ways of configuring deployed services?
Do you mean feature flags? This enable you to change the configuration at the runtime. Ex: A/B Testing and changing a behavior for a subset of users, disable feature when you want it (particularly useful when you are in Trunk Based Development and don't want to deploy a beta feature to everyone for example).
No I mean an entire framework and set of software components for doing feature flags.
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#14I can see that this might be very useful, since it is more some kind of application configuration specification that goes far beyond simple flags. In the end the common provider that works securely across all services and clients is probably the real problem.
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#15Earlier quoted context omitted.
Do you mean feature flags? This enable you to change the configuration at the runtime. Ex: A/B Testing and changing a behavior for a subset of users, disable feature when you want it (particularly useful when you are in Trunk Based Development and don't want to deploy a beta feature to everyone for example).
No I mean an entire framework and set of software components for doing feature flags.
Clearly you haven't worked at an org that uses something like this extensively (LaunchDarkly for example.)
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#16I don’t get it. Why is this needed above and beyond the standard ways of configuring deployed services?
Do you mean feature flags? This enable you to change the configuration at the runtime. Ex: A/B Testing and changing a behavior for a subset of users, disable feature when you want it (particularly useful when you are in Trunk Based Development and don't want to deploy a beta feature to everyone for example).
But why do you need an external service for that? Isn’t that basically a single DB table with a name and an on/off value for each flag (or maybe an integer for multiple options)?
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#17Earlier quoted context omitted.
Do you mean feature flags? This enable you to change the configuration at the runtime. Ex: A/B Testing and changing a behavior for a subset of users, disable feature when you want it (particularly useful when you are in Trunk Based Development and don't want to deploy a beta feature to everyone for example).
But why do you need an external service for that? Isn’t that basically a single DB table with a name and an on/off value for each flag (or maybe an integer for multiple options)?
In it's simplest incarnation, yes it could be just a single DB table with boolean flags.
However there are a lot of connected needs that most real world-usages run into:
- Per-user toggles of configuration values
- Per-user dynamic evaluation based on a set of rules
- Change history, to see what the flag value was at time of an incident
- A/B testing of features and associated setting of tracking parameters
- Should be controllable by e.g. a marketing/product manager and not only software engineers
That can quickly grow into something where it's a lot easier to reach for an existing well thought out solutions rather than trying to home-grow it.
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#18Martin Fowler about feature flags: https://martinfowler.com/articles/feature-toggles.html
No, that is Pete Hudgson on martinfowler.com. Most articles on martinfowler.com haven't been written by Martin Fowler himself in years. It's best thought of as a publishing venue for Thoughtworks.
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#19Nice! Sometime ago i made a small poc with usage on
Frontend (nextjs)
Backcend (js)
Flag provider (flagd + flag api that serves json flags from db)
Cool stuff
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#20Earlier quoted context omitted.
But why do you need an external service for that? Isn’t that basically a single DB table with a name and an on/off value for each flag (or maybe an integer for multiple options)?
In it's simplest incarnation, yes it could be just a single DB table with boolean flags. However there are a lot of connected needs that most real world-usages run into: - Per-user toggles of configuration values - Per-user dynamic evaluation based on a set of rules - Change history, to see what the flag value was at time of an incident - A/B testing of features and associated setting of tracking parameters - Should…
In microservice world.
Do you want to track features in each service or have a source of truth using flagd
I prefer central source of truth