SDKs
OpenFeature providers
Featurevisor providers let applications use Featurevisor through the standard OpenFeature API.
Choose a provider#
| Platform | Provider documentation |
|---|---|
| Node.js | Node.js provider |
| Browser | Browser provider |
| Go | Go provider |
| Swift | Swift provider |
| Java | Java provider |
| Kotlin | Kotlin provider |
| Ruby | Ruby provider |
| Python | Python provider |
| PHP | PHP provider |
| Rust | Rust provider |
| Elixir | Elixir provider |
Every publicly available general purpose Featurevisor SDK now has an OpenFeature provider. The providers are optional integrations. The regular Featurevisor SDK APIs remain available and do not depend on OpenFeature.
Flag keys#
OpenFeature exposes one flag key while Featurevisor supports flags, variations, and variables. Providers use this convention:
| OpenFeature key | Featurevisor evaluation |
|---|---|
checkout | Flag value from evaluateFlag("checkout") |
checkout:variation | Variation value from evaluateVariation("checkout") |
checkout:title | Variable value from evaluateVariable("checkout", "title") |
variable:supportEmail | Global variable value from evaluateVariable("supportEmail") |
Use the resolver matching the expected value. Boolean variables use the boolean resolver. String variables and variations use the string resolver. Numeric variables use the integer, float, double, or number resolver provided by the platform. Arrays, objects, structures, and JSON variables use the object resolver.
The first : separates the key parts. A feature key comes first for flags, variations, and variables inside features. The reserved variable prefix selects a global variable instead. This keeps a feature variable such as checkout:variable unambiguous.
Every provider supports global variables and lets you configure the separator, reserved variation selector, and global variable prefix if those values conflict with project keys. The global variable prefix defaults to variable. Refer to the provider page for the option names used by its language.
Evaluation context#
The final OpenFeature evaluation context is copied into Featurevisor without mutating it. Its targeting key is also exposed as userId by default, which matches the common Featurevisor bucketing convention. Configure the provider's targeting key field when a project buckets by another attribute.
OpenFeature owns context merging and hook execution. Featurevisor modules continue to run inside Featurevisor evaluation. Providers do not translate OpenFeature hooks into Featurevisor modules or modules into hooks.
Resolution details#
Providers return the OpenFeature default value when a feature is missing, a value has the wrong type, or evaluation fails. They map details as follows:
| Featurevisor result | OpenFeature result |
|---|---|
| Forced, required, sticky, or rule match | TARGETING_MATCH |
| Traffic allocation | SPLIT |
| Disabled result | DISABLED |
| Normal default or no match | DEFAULT |
| Missing feature or variable | ERROR with FLAG_NOT_FOUND |
| Wrong resolver type | ERROR with TYPE_MISMATCH |
| Invalid datafile JSON | ERROR with PARSE_ERROR |
Where supported by the OpenFeature SDK, flag metadata includes the Featurevisor reason, feature and variable keys, revision, schema version, and matching rule or bucket details. Variation evaluations also expose the selected variation as the OpenFeature variant.
Tracking#
Where the platform OpenFeature SDK exposes tracking, tracking is a no-op unless the provider is configured with an onTrack callback. This lets the application forward OpenFeature tracking events to its analytics system without adding tracking behaviour to the core Featurevisor SDK. The current Rust and Elixir OpenFeature SDKs do not expose provider tracking, so their Featurevisor providers document that platform limitation instead.
Featurevisor instance ownership#
Providers can either create a Featurevisor instance from options or reuse one supplied by the application.
When a provider creates the instance, the provider owns it and closes it during provider shutdown. When an application supplies an existing instance, the application retains ownership. Provider shutdown leaves the shared instance open so other consumers can continue using it. The application should close it after every consumer is finished.
If both an instance and Featurevisor construction options are supplied, the existing instance takes precedence. Provider-specific options for key mapping and tracking still apply. The platform provider pages show the exact constructor and lifecycle APIs.
Swift and PHP also expose an explicit close or shutdown method for application-owned provider lifecycles.
Example application#
The Featurevisor OpenFeature example for Node.js is a complete application using the server provider. It loads a published datafile, evaluates through an OpenFeature client, and tests flags, variations, variables, context mapping, default values, and lifecycle behaviour.