open-feature / open-feature/spec
Evaluation API - bulk evaluation
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.3k
- Forks
- 58
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 2
Description
Hi,
I faced with 2 scenarios which is uncovered by specification but they looks very important for dynamic-context paradigm.
Both scenarios actually linked with atomicity of configuration in admin system and data consistency.
-
If we have some configuration in admin we want to have guarantees that multiple calls of flags will be executed on same version of this configuration. Because if we perform two calls to get 'foo' and 'bar' so between requesting 'bar' configuration in admin may be changed and cause inconsistent state due to foo was already received with previous version.
-
One more case related to atomicity but also crucial to avoid multiple request instead single request. For example using some flow we use 2 or more flags. So we need to make 2 or more calls by network to get evaluation for same context (for example targetingKey/userId).
So in additional to problem related to consistency we also have additional network calls which also can be failed and dramatically increase overall latency to process some business request/payload.
I want propose to add new API method to request flags in bulk mode with some specified evaluation context for all of them.
Looks like:
List/Map evaluations = client.getBulkEvaluation(flagsAndDefaults, evaluationContext)
Where flagsAndDefault should represent name of flag and associated default. It also can be map/dict or some structure.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing Evaluation API and how evaluation context and default values are specified. Define the bulk-evaluation contract, including configuration-version consistency and the flags-and-defaults input, then document the expected result and failure behavior. Done means the specification clearly describes one bulk request for multiple flags under one context.
Written by the indexing model from the issue text.
Assessment
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100