-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Working with multiple UnleashClient instances #210
Comments
Thanks for the suggestion! I'm wondering what the use-case is for using more than one Unleash client on the browser side. It's not that common to run two Unleash clients in parelell, so while I agree that this useful IF you use several unleash clients I'd love to understand the use case better. |
Hello! My use case consists of a large frontend codebase in which multiple (4, at least) development teams contribute in some well bounded contexts and some other shared contexts. We filter flags for each team based on prefix and use the OpenFeature API configured with a provider which basically wraps this library features. Given the scenario of bounded contexts within the same monolith project, we use the OpenFeature domains resource, which gives us ability to use the same OpenFeature API throughout the whole codebase and each team only needs to specify its "domain" name when evaluating flags. It looks something like this: import { OpenFeature } from '@openfeature/web-sdk';
await OpenFeature.setProviderAndWait('domainN1', new UnleashClientProviderWrapper(...));
await OpenFeature.setProviderAndWait('domainN2', new UnleashClientProviderWrapper(...));
await OpenFeature.setProviderAndWait('domainN3', new UnleashClientProviderWrapper(...));
const domainN2FeatureEnabled = OpenFeature.getClient('domainN2').getBooleanValue('FLAG_NAME', false); Each |
@andretibolaintelipost this PR should fix your issue: #225 |
Yes, this will definitely work in my use case. Thanks!! |
Version 3.6.0-beta.0 has been released and you can test it. Once we gather enough feedback from the beta release we'll promote it to a proper release. |
Describe the feature request
Make the
LocalStorageProvider
class be able to receive an optional suffix to identify eachUnleashClient
, otherwise when running two or more instances, the last to store its toggles will override other instances toggles, because theLocalStorageProvider
is always persisting in theunleash:repository:repo
key. I have been able to workaround this problem by creating my ownIStorageProvider
implementation, but it would be nice to have this out of the box for all users.Background
I am using unleash-proxy-client wrapped within OpenFeature Web SDK and using more than one
UnleashClient
instance in my frontend project. OpenFeature has the concept of "domains", which allows multiple provider instances to exist concurrently, each bounded to a "domain" key. This is useful for me since my project is a monolith codebase with different development teams working on itSolution suggestions
I am thinking that the UnleashClient constructor would pass the
appName
to theLocalStorageProvider
constructor, so eachUnleashClient
would have an unique local storage keyThe text was updated successfully, but these errors were encountered: