Closed fahad19 closed 11 months ago
my 2 cents is that if there's a way we can achieve this in "userland" (e.g. using "foo:bar" key names with semantics that the provider understands) then we should strongly prefer that over changing/extending the spec
my 2 cents is that if there's a way we can achieve this in "userland" (e.g. using "foo:bar" key names with semantics that the provider understands) then we should strongly prefer that over changing/extending the spec
@moredip: you are very much right in suggesting if we can a solution in the userland for scoped variations/variables like using foo:bar
as keys.
I like this suggestion. and likely creating a new Featurevisor provider for OpenFeature following this pattern.
my response would be the same if I were an OpenFeature maintainer.
the only remaining thing for me is to figure out the "activation" event to be triggered at will, which is discussed in above thread.
summary:
featureKey:variableKey
pattern, keeping the OpenFeature API the samereally appreciate all the inputs <3
I would have defended the OpenFeature API the same way to not have any further tweaks in the API to accommodate Featurevisor or any other solutions.
will take the learnings from here and build the provider at some point.
thanks everyone! 🙌
This PR
Introduces a new OFEP as per a previous discussion on Slack.
Proposes a new model for features, breaking it down into 3 kinds of values all scoped under a single feature:
Notes
This is being proposed to help open up the possibility to create OpenFeature providers for Featurevisor: https://featurevisor.com/
SDK docs showing examples of the proposed feature model:
Further guides for the concepts introduced:
I understand this proposal can be very different than your overall vision around feature flags, but I feel it's worth raising it to you all because it enables many other tools (both Open Source & SaaS) to create OpenFeature Providers then ❤️