harness-community / openfeature-go-provider Goto Github PK
View Code? Open in Web Editor NEWLicense: Apache License 2.0
License: Apache License 2.0
https://docs.openfeature.dev/docs/specification/sections/providers#provider-hooks
Provider hooks
A provider hook exposes a mechanism for provider authors to register hooks to tap into various stages of the flag evaluation lifecycle. These hooks can be used to perform side effects and mutate the context for purposes of the provider. Provider hooks are not configured or controlled by the application author.
Requirement 2.10
The provider interface MUST define a provider hook mechanism which can be optionally implemented in order to add hook instances to the evaluation life-cycle.
class MyProvider implements Provider {
//...
readonly hooks: Hook[] = [new MyProviderHook()];
// ..or alternatively..
getProviderHooks(): Hook[] {
return [new MyProviderHook()];
}
//...
}
Reference Provider (JAVA): https://github.com/splitio/split-openfeature-provider-java/blob/main/src/main/java/io/split/openfeature/SplitProvider.java
Conventions Checklist: https://docs.openfeature.dev/docs/reference/concepts/provider/#checklist
https://docs.openfeature.dev/docs/specification/sections/providers#requirement-212
Requirement 2.12
In cases of abnormal execution, the evaluation details structure's error message field MAY contain a string containing additional detail about the nature of the error.
Reference Provider (JAVA): https://github.com/splitio/split-openfeature-provider-java/blob/main/src/main/java/io/split/openfeature/SplitProvider.java
Conventions Checklist: https://docs.openfeature.dev/docs/reference/concepts/provider/#checklist
https://docs.openfeature.dev/docs/specification/sections/providers#flag-value-resolution
Flag Value Resolution
Providers are implementations of the feature provider interface, which may wrap vendor SDKs, REST API clients, or otherwise resolve flag values from the runtime environment.
Requirement 2.2
The feature provider interface MUST define methods to resolve flag values, with parameters flag key (string, required), default value (boolean | number | string | structure, required) and evaluation context (optional), which returns a flag resolution structure.
resolveBooleanValue(flagKey, defaultValue, context);```
see: [flag resolution structure](https://docs.openfeature.dev/docs/specification/types#flag-resolution), [flag value resolution](https://docs.openfeature.dev/docs/specification/glossary#flag-value-resolution)
---
Reference Provider (JAVA): https://github.com/splitio/split-openfeature-provider-java/blob/main/src/main/java/io/split/openfeature/SplitProvider.java
Conventions Checklist: https://docs.openfeature.dev/docs/reference/concepts/provider/#checklist
https://docs.openfeature.dev/docs/specification/sections/providers#condition-29
Condition 2.9
The implementation language supports generics (or an equivalent feature).
Conditional Requirement 2.9.1
The flag resolution structure SHOULD accept a generic argument (or use an equivalent language feature) which indicates the type of the wrapped value field.
// example boolean flag value resolution with generic argument
ResolutionDetails<boolean> resolveBooleanValue(string flagKey, boolean defaultValue, context: EvaluationContext);
// example string flag value resolution with generic argument
ResolutionDetails<string> resolveStringValue(string flagKey, string defaultValue, context: EvaluationContext);
// example number flag value resolution with generic argument
ResolutionDetails<number> resolveNumberValue(string flagKey, number defaultValue, context: EvaluationContext);
// example structure flag value resolution with generic argument
ResolutionDetails<MyStruct> resolveStructureValue(string flagKey, MyStruct defaultValue, context: EvaluationContext);
Reference Provider (JAVA): https://github.com/splitio/split-openfeature-provider-java/blob/main/src/main/java/io/split/openfeature/SplitProvider.java
Conventions Checklist: https://docs.openfeature.dev/docs/reference/concepts/provider/#checklist
https://docs.openfeature.dev/docs/specification/sections/providers#requirement-27
Requirement 2.7
In cases of normal execution, the provider MUST NOT populate the flag resolution structure's error code field, or otherwise must populate it with a null or falsy value.
Reference Provider (JAVA): https://github.com/splitio/split-openfeature-provider-java/blob/main/src/main/java/io/split/openfeature/SplitProvider.java
Conventions Checklist: https://docs.openfeature.dev/docs/reference/concepts/provider/#checklist
https://docs.openfeature.dev/docs/specification/sections/providers#requirement-24
Requirement 2.4
In cases of normal execution, the provider MUST populate the flag resolution structure's value field with the resolved flag value.
Reference Provider (JAVA): https://github.com/splitio/split-openfeature-provider-java/blob/main/src/main/java/io/split/openfeature/SplitProvider.java
Conventions Checklist: https://docs.openfeature.dev/docs/reference/concepts/provider/#checklist
https://docs.openfeature.dev/docs/specification/sections/providers#requirement-26
Requirement 2.6
The provider SHOULD populate the flag resolution structure's reason field with "DEFAULT", "TARGETING_MATCH", "SPLIT", "DISABLED", "UNKNOWN", "ERROR" or some other string indicating the semantic reason for the returned flag value.
As indicated in the definition of the flag resolution structure, the reason should be a string. This allows providers to reflect accurately why a flag was resolved to a particular value.
Reference Provider (JAVA): https://github.com/splitio/split-openfeature-provider-java/blob/main/src/main/java/io/split/openfeature/SplitProvider.java
Conventions Checklist: https://docs.openfeature.dev/docs/reference/concepts/provider/#checklist
https://docs.openfeature.dev/docs/specification/sections/providers#flag-value-resolution
Condition 2.3
The implementing language type system differentiates between strings, numbers, booleans and structures.
Conditional Requirement 2.3.1
The feature provider interface MUST define methods for typed flag resolution, including boolean, numeric, string, and structure.
ResolutionDetails resolveBooleanValue(string flagKey, boolean defaultValue, context: EvaluationContext);
// example string flag value resolution
ResolutionDetails resolveStringValue(string flagKey, string defaultValue, context: EvaluationContext);
// example number flag value resolution
ResolutionDetails resolveNumberValue(string flagKey, number defaultValue, context: EvaluationContext);
// example structure flag value resolution
ResolutionDetails resolveStructureValue(string flagKey, JsonObject defaultValue, context: EvaluationContext);
Reference Provider (JAVA): https://github.com/splitio/split-openfeature-provider-java/blob/main/src/main/java/io/split/openfeature/SplitProvider.java
Conventions Checklist: https://docs.openfeature.dev/docs/reference/concepts/provider/#checklist
https://docs.openfeature.dev/docs/specification/sections/flag-evaluation
Requirement 1.2.2
The client interface MUST define a metadata member or accessor, containing an immutable name field or accessor of type string, which corresponds to the name value supplied during client creation.
client.getMetadata().getName(); // "my-client"
https://docs.openfeature.dev/docs/specification/sections/providers#requirement-211
Requirement 2.11
In cases of normal execution, the provider MUST NOT populate the flag resolution structure's error message field, or otherwise must populate it with a null or falsy value.
Reference Provider (JAVA): https://github.com/splitio/split-openfeature-provider-java/blob/main/src/main/java/io/split/openfeature/SplitProvider.java
Conventions Checklist: https://docs.openfeature.dev/docs/reference/concepts/provider/#checklist
https://docs.openfeature.dev/docs/specification/sections/flag-evaluation
Requirement 1.1.1
The API, and any state it maintains SHOULD exist as a global singleton, even in cases wherein multiple versions of the API are present at runtime.
It's important that multiple instances of the API not be active, so that state stored therein, such as the registered provider, static global evaluation context, and globally configured hooks allow the API to behave predictably. This can be difficult in some runtimes or languages, but implementors should make their best effort to ensure that only a single instance of the API is used.
Requirement 1.1.2
The API MUST provide a function to set the global provider singleton, which accepts an API-conformant provider implementation.
// example provider mutator
OpenFeature.setProvider(new MyProvider());
Pseudo:
OpenFeature.setProvider(new HarnessFF());
https://docs.openfeature.dev/docs/specification/sections/providers#requirement-21
The provider interface MUST define a metadata member or accessor, containing a name field or accessor of type string, which identifies the provider implementation.
provider.getMetadata().getName(); // "my-custom-provider"
Reference Provider (JAVA): https://github.com/splitio/split-openfeature-provider-java/blob/main/src/main/java/io/split/openfeature/SplitProvider.java
Conventions Checklist: https://docs.openfeature.dev/docs/reference/concepts/provider/#checklist
https://docs.openfeature.dev/docs/specification/sections/flag-evaluation
Requirement 1.2.1
The client MUST provide a method to add hooks which accepts one or more API-conformant hooks, and appends them to the collection of any previously added hooks. When new hooks are added, previously added hooks are not removed.
// example hook attachment
client.addHooks([new MyHook()]);
See hooks for details.
https://docs.openfeature.dev/docs/specification/sections/flag-evaluation
Requirement 1.1.3
The API MUST provide a function to add hooks which accepts one or more API-conformant hooks, and appends them to the collection of any previously added hooks. When new hooks are added, previously added hooks are not removed.
// example hook attachment
OpenFeature.addHooks([new MyHook()]);
https://docs.openfeature.dev/docs/specification/sections/providers#requirement-25
Requirement 2.5
In cases of normal execution, the provider SHOULD populate the flag resolution structure's variant field with a string identifier corresponding to the returned flag value.
For example, the flag value might be 3.14159265359, and the variant field's value might be "pi".
The value of the variant field might only be meaningful in the context of the flag management system associated with the provider. For example, the variant may be a UUID corresponding to the variant in the flag management system, or an index corresponding to the variant in the flag management system.
Reference Provider (JAVA): https://github.com/splitio/split-openfeature-provider-java/blob/main/src/main/java/io/split/openfeature/SplitProvider.java
Conventions Checklist: https://docs.openfeature.dev/docs/reference/concepts/provider/#checklist
https://docs.openfeature.dev/docs/specification/sections/providers#requirement-28
Requirement 2.8
In cases of abnormal execution, the provider MUST indicate an error using the idioms of the implementation language, with an associated error code and optional associated error message.
The provider might throw an exception, return an error, or populate the error code object on the returned flag resolution structure to indicate a problem during flag value resolution.
See error code for details.
// example throwing an exception with an error code and optional error message.
throw new ProviderError(ErrorCode.INVALID_CONTEXT, "The 'foo' attribute must be a string.");
Reference Provider (JAVA): https://github.com/splitio/split-openfeature-provider-java/blob/main/src/main/java/io/split/openfeature/SplitProvider.java
Conventions Checklist: https://docs.openfeature.dev/docs/reference/concepts/provider/#checklist
https://docs.openfeature.dev/docs/specification/sections/flag-evaluation
Requirement 1.1.5
The API MUST provide a function for creating a client which accepts the following options:
name (optional): A logical string identifier for the client.
// example client creation and retrieval
OpenFeature.getClient({
name: "my-openfeature-client",
});
The name is a logical identifier for the client.
Requirement 1.1.6
The client creation function MUST NOT throw, or otherwise abnormally terminate.
Clients may be created in critical code paths, and even per-request in server-side HTTP contexts. Therefore, in keeping with the principle that OpenFeature should never cause abnormal execution of the first party application, this function should never throw. Abnormal execution in initialization should instead occur during provider registration.
https://docs.openfeature.dev/docs/specification/sections/flag-evaluation
Requirement 1.1.4
The API MUST provide a function for retrieving the metadata field of the configured provider.
// example provider accessor
OpenFeature.getProviderMetadata();
See provider for details.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.