Open beeme1mr opened 7 months ago
Is there any reason this couldn't be added to both paradigms? It's less important for server, but I don't think it adds too much complexity.
Is there any reason this couldn't be added to both paradigms? It's less important for server, but I don't think it adds too much complexity.
Think so too, for the server this could just be a little convenience.
I'll work on adding this to the spec. In the meantime, here's how it should work in JavaScript.
Overview
When an SDK follows the static-context paradigm, an update to context may lead to an expensive async operation. For that reason, it's recommended to set known context prior to setting the provider. If the context is set later, even immediately after initialization registration, another call to async call may be made.
Set context before set provider
In this scenario, one call is made to the provider during initilzation.
Set context after set provider
In this scenario, two calls may be made to the provider because the context changes after initialization.
Proposal
The proposal would ensure that context is available to the provider during initialization. Context can still be updated using
OpenFeature.setContext()
if necessary, but this would help users avoid unnecessary delays during start up.Requirements
Dependencies
References