featurevisor / featurevisor

Feature flags, experiments, and remote config management with GitOps

Home Page:https://featurevisor.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

OpenFeature providers

toddbaert opened this issue · comments

Hello! I'm one of the maintainers in OpenFeature - a vendor-neutral feature flagging standard (https://openfeature.dev/, https://github.com/open-feature/). I saw your project and I think it's really compelling.

Basically, OpenFeature may be a shortcut for featurevisor to get SDKs in additional languages. Somebody familiar with the communication layer of featurevisor could write a provider for a target language we support (JS, .NET, Java, Go, PHP, etc) and avoid having to write an entire SDK. There's also be the benefits of OpenFeature's extensions/integrations (OpenTelemetry, etc). Our contrib repos will even handle the publishing/CI for you if you'd like to avoid that burden (we publish community-maintained providers to maven central, nuget, etc).

There's already a number of providers available from vendors and OSS projects. Let us know if this sounds interesting to you.

@toddbaert: thanks for the kind feedback! OpenFeature looks really interesting.

Given Featurevisor is primarily maintained by me and I am mostly working with JavaScript, I don't see myself writing adapters for OpenFeature/Featurevisor in other languages anytime soon :(

Always open to community contributions of course.

My primary focus now is to get to a stable v1 soon, both in terms of the datafile generation and also the JavaScript SDK. It's too important to get the core done right before I jump into supporting more languages.

Regarding official SDKs, I am aware some folks are looking into porting Featurevisor to other languages by imitating the API/code as exists in the JavaScript SDK, which is gonna be a lot more easier for new contributors to do than learning another abstraction layer on top of it (in the form of OpenFeature).

I see value in OpenFeature as a project, but I am personally not seeing any big benefit from my perspective as a maintainer of Featurevisor at this early stage.

@toddbaert: I have posted a message on Slack asking if OpenFeature's Provider API can adapt to Featurevisor concepts, like:

  • flag values (boolean)
  • variations (strings)
  • variables (key/value pairs with various types)

Slack link: https://cloud-native.slack.com/archives/C0344AANLA1/p1691950718814419

Copy/pasted here for convenience:

Topic: Featurevisor provider for OpenFeature https://featurevisor.com/docs/sdks/

I released this Open Source project of mine, that's Git-based for managing feature flags which can contain:

  • on/off values (boolean flags)
  • variations (string values for a/b tests based on bucketing)
  • variables (key/value pairs of data of various types)

I am finally at a stage where the core and the SDK is stable enough to explore more integrations, and was reading the > Provider API docs of OpenFeature: https://openfeature.dev/docs/reference/technologies/server/javascript#providers

Found a reference implementation here: https://openfeature.dev/docs/reference/concepts/provider#examples

I am curious if it is even possible to incorporate concepts like variations and variables next to flag values with OpenFeature providers at all.

so far, my understanding is:

  • OpenFeature supports only one type of value, that is the flag's own feature (which can be of various primitive types)
  • Featurevisor goes beyond just flag value and has a clear separation by introducing concepts like variation and variables, which doesn't fit OpenFeature's model

I will submit a new OFEP for further discussion with OpenFeature team: https://github.com/open-feature/ofep

OpenFeature does support two different methods per data type.

One simply returns the value of the requested data type like this:

const isFeatureEnabled = await client.getBooleanValue('flag-key', false);

if (isFeatureEnabled) {
 console.log("new feature is enabled");
}

The other one returns a rich payload with useful troubleshooting and runtime information. You can use it like this:

const featureDetails = await client.getBooleanDetails('flag-key', false);

if (featureDetails.value) {
 console.log("new feature is enabled");
}

You can see an overview of the evaluation details payload here. This could potentially be expanded to include variable support.

thanks @beeme1mr for this.

In Featurevisor JavaScript SDK, it also has something similar for providing evaluation details for each kind of data separately:

  • flag: instance.evaluateFlag(featureKey, context)
  • variation: instance.evaluateVariation(featureKey, context)
  • variable: instance.evaluateVariable(featureKey, variableKey, context)

docs: https://featurevisor.com/docs/sdks/#evaluation-details