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 |
| Ruby | Ruby provider |
| Python | Python provider |
| PHP | PHP 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") |
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 feature key from the selector. Every provider lets you configure the separator and reserved variation selector if those values conflict with project keys.
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#
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 behavior to the core Featurevisor SDK.
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.