Closed justinabrahms closed 1 year ago
@justinabrahms how would you feel about something like this?
import { OpenFeature } from '@openfeature/js-sdk';
OpenFeature.setProvider(new MyGlobalProvider());
const client = OpenFeature.getClient();
client.overrideProvider(new MyClientProvider());
The idea would be to only allow a single global provider at a time but allow clients to optionally set a new provider that only affects themselves.
@beeme1mr A different way to say that:
~I don't love either of those.~
EDIT: Just realized that my solution does item 2 as well. So even if I don't love it.. it's what we got. The big question is item 1, then.
All good here. Brings utility to the existing named clients (but also will be a breaking change, just to note).
My intent would be to still allow setProvider(provider)
to set the default one, which should keep it backwards compatible, yes?
Hey @justinabrahms, would you mind putting together a quick prototype when you have a moment? That may be a good way to move this OFEP along and would make updating the spec straightforward.
Here's a prototype: https://github.com/open-feature/java-sdk/pull/388
Here's a prototype: open-feature/java-sdk#388
Thanks @justinabrahms I'll take a look at this tomorrow!
Here's a prototype: open-feature/java-sdk#388
@justinabrahms This makes sense to me. I have a couple thoughts/questions:
getProviderForClientOrDefault(String name)
would change to getProviderForScopeOrDefault(String scope)
? I know it's just naming, but I think referring to this as a "scope" adds clarity, and even allows us to future proof things a bit; there may be other things we want to "scope" in this way. See earlier discussion here. We could add this term to our documentation and glossary.cc @thiyagu06 @tcarrio @beeme1mr @thomaspoignant
@toddbaert I dislike using the term 'scope' for the client name. It introduces another term, which I think confuses things. What we're really talking about is binding a client to a specific provider. It's not some "scoping key" that is being bound. It's the named client.
I would expect that initialization would happen for any provider that's registered. I'm unclear about how events would be supported. One option would be a single event stream with a parameter of what is effected or we could have multiple event streams. I don't feel strongly.
I think API shutdown would be global.
I can agree with @justinabrahms I don't really like the word scope in this context it can be misleading and it is not completely obvious that we are talking about the client name.
I would expect that initialization would happen for any provider that's registered. I'm unclear about how events would be supported. One option would be a single event stream with a parameter of what is effected or we could have multiple event streams. I don't feel strongly.
@justinabrahms my main concern was to confirm that if provider associated with client X gets a "flags change" event, only client X would get that event, right?
@toddbaert I'm not fully up to speed on the events stuff. I don't think there's a technical reason why the thing you're saying can't work though.
refs: #49