Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add proposal for Provider Hook #22

Merged
merged 4 commits into from
Jul 29, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions 005-OFEP-provider-hook.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
## 005-OFEP-provider-hook.md

## State: APPROVED

As a part of the Provider implementation by the Flag Management Systen, there is a need to have standardized support for hooks specific to the Provider. The
Provider Hook(s) should be specific to the provider implementation and implement the various defined stages of the Hook interface as applicable to the
specific provider.

## Assumptions

The Provider Hook is transparent to the application developer. The Provider may choose to document certain default behavior/feature in specific stages of the
Provider Hook as relevant to the application and the application developer may be allowed to override the default feature.

## Example Use Case

Flag Management System X provides the option to add Experimentation as an extension of Feature Flag. The user creates a Feature Flag, runs basic on/off
evaluations of the Feature targeting specific audience and then wants to run A/B tests and hence adds the Experimentation aspects to the Feature Flag.

The Provider needs to generate event specific to the Experimentation implementation on successful flag evaluation. The system wants to use a Provider Hook
to do the following for each evaluation
1. Run initialization operations (Use the _before_ stage of the Hook)
2. Run an event publish operation on successful flag evaluation operation (Use the _after_ stage of the Hook)
3. Provide the option to the application developer to override the event publish operation
1. The application developer may choose not to immediately publish the event on evaluation, but decide to publish it (or not) later based on other
application specific logic

For applications not required to override the default behavior, there is no extra step needed to add any other hooks. The Provider Hook is transparent to
the application developer.

## Example Workflow

1. At the time of registering the provider (OpenFeature.setProvider), Provider implementation can register one or more Provider Hook(s)
2. Provider Hook implements the _before_ and _after_ and any other relevant stages to run the relevant provider logic.
3. Provider documents the relevant default behavior (e.g. automatic publish of Experimentation event on successful evaluation)
4. Provider provides an implementation of an Invocation Hook to override this default behavior as a part of the Provider SDK.
5. If needed, the application developer uses the invocation hook to override specific default behavior of the provider by using Hook Hints e.g. turn off
default event publish behavior

## Hook Ordering

The Hooks should be executed in specific order.

* before: API, Client, Invocation, Provider
beeme1mr marked this conversation as resolved.
Show resolved Hide resolved
* Provider does initialization after Invocation
* after: Provider, Invocation, Client, API
* error (if applicable): Provider, Invocation, Client, API
* finally: Provider, Invocation, Client, API