Define initial scope
beeme1mr opened this issue · 0 comments
The purpose of this issue is to document the current status of the project and propose a high-level roadmap for achieving general availability.
Spec
The spec is an important aspect of OpenFeature. We need to reach a level of stability as quickly as possible so that SDKs, provider implementations, and hooks can be created.
Research
Server-side research
Research is nearly complete for the server-side. The outcome from that research can be seen below:
Areas that may still require additional research:
- Request based context propagation using something like continuous local storage or thread local storage. A proof of concept was added to the playground.
Client-side research
Client-side feature flagging will be a requirement for a GA release. Conceptually, they're similar to server-side feature flags but they introduce additional complexities that need to be considered. However, the majority of our effort so far has been on server-side feature flagging.
Web
Research for feature flagging client-side on the web is currently in progress.
Mobile
Research for feature flagging client-side on mobile has not been started.
Sections of the spec
Flag Evaluation
The flag evaluation section is available in an experimental state here.
Hooks
The hook section is available in an experimental state here.
There are still some ongoing discussions including:
Provider
The provider is available in an experimental state here. It's important that vendors keep a close eye on this part of the spec in order to ensure OpenFeature compatibility with their product.
Evaluation Context
The evaluation context is currently in progress. This part of the spec simply provides semantic meaning to some properties on the context object. This will provide consistency between different providers. For example, one vendor may have a userId property and another may have userKey. OpenFeature needs to provide enough structure to providers in order to map context properly.
There's an open PR to add evaluation context to the spec. That PR can be found here.
Event Subscription
Event subscription is at the proposal stage. Many vendors provide an event-based API that allows developers to subscribe to events like onReady or flagUpdate.
Bulk evaluations
Bulk evaluation is at the proposal stage. This may be useful on the client, or when a developer wants to include the results of multiple flag evaluations on a request.
Tracking Events
Tracking events are at the proposal stage. Events can be associated with flag evaluations, which is particularly useful for A/B testing. This concept does not exist in all providers. However, we could potentially introduce the concept of a tracking provider. The provider could either be a provider that supports this concept or another event tracking tool, e.g. Segment.
SDKs
Server-side
Java
The Java SDK is under active development. You can see the repo here.
Node JS
The NodeJs SDK is under active development. You can see the repo here.
Golang
The Golang SDK is under active development. You can see the repo here.
Python
The Python SDK is under active development. You can see the repo here.
.NET
Development hasn't started on the .NET SDK, but it is expected to begin soon.
Client-side
Web
The client-side web SDK depends on the spec research listed above. It's unclear at this time how similar this SDK will be to the NodeJS SDK. Code reuse may be an option.
Mobile
Android
The client-side Android SDKs depends on the spec research listed above. Its priority still needs to be determined.
iOS
The client-side iOS SDKs depends on the spec research listed above. Its priority still needs to be determined.
React Native
The client-side React Native SDKs depends on the spec research listed above. Its priority still needs to be determined.
Providers and Plugins
Providers and plugins will need to be developed for each of the supported languages. A contrib repo for each language should be created. It can act as a central location for community managed providers and plugins.
Maintainers and workflows will need to be defined to ensure that only high quality providers and plugins are included.
Documentation
Documentation will need to be created and available online. Docusaurus seems to be the popular choice.
Cloud Native
The cloud native operator and provider should be moved into a separate section. Perhaps a dedicated Special Interest Group (SIG) should be defined for this initiative. The goal is to provide a spec compliant provider that utilizes Kubernetes constructs. Progress can be monitored here.