Provider to client mappings

[justinabrahms]

refs: #49

[thomaspoignant]

Quick feedback on the format, you're file is not finishing by .md so it does not format well in Github.

[beeme1mr]

@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.

[justinabrahms]

@beeme1mr A different way to say that:

1. libraries must never create a client. They must be passed a client.
2. If you need to juggle multiple providers (e.g. flagsmith for some stuff, flagd for others, file-based for a third), you will need to juggle multiple clients.

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.

[tcarrio]

All good here. Brings utility to the existing named clients (but also will be a breaking change, just to note).

[justinabrahms]

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?

[beeme1mr]

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.

[justinabrahms]

Here's a prototype: open-feature/java-sdk#388

[toddbaert]

Here's a prototype: open-feature/java-sdk#388

Thanks @justinabrahms I'll take a look at this tomorrow!

[toddbaert]

Here's a prototype: open-feature/java-sdk#388

@justinabrahms This makes sense to me. I have a couple thoughts/questions:

• How do you feel about using "scope" to refer to the "name" for a client. So 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.
• I suppose initialization and events (both not yet completely spec'd out) would be scoped similarly? So change events emitted in a particular provider only impact clients in that provider scope? and setting a new provider for a given scope would shut down the previous one?
• Would API shutdown (discussed here) still be global? Would there be a need to shutdown only certain providers? I'm leaning towards no, since I think the shutdown is really only useful for terminating the application, in which case all providers should probably be stopped.

cc @thiyagu06 @tcarrio @beeme1mr @thomaspoignant

[justinabrahms]

@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.

[thomaspoignant]

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.

[toddbaert]

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?

[justinabrahms]

@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.