Skip to content
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

Closed
andretibolaintelipost opened this issue May 23, 2024 · 5 comments · Fixed by #225
Closed

Working with multiple UnleashClient instances #210

andretibolaintelipost opened this issue May 23, 2024 · 5 comments · Fixed by #225
Assignees
Labels
enhancement New feature or request

Comments

@andretibolaintelipost
Copy link

Describe the feature request

Make the LocalStorageProvider class be able to receive an optional suffix to identify each UnleashClient, otherwise when running two or more instances, the last to store its toggles will override other instances toggles, because the LocalStorageProvider is always persisting in the unleash:repository:repo key. I have been able to workaround this problem by creating my own IStorageProvider 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 it

Solution suggestions

I am thinking that the UnleashClient constructor would pass the appName to the LocalStorageProvider constructor, so each UnleashClient would have an unique local storage key

@FredrikOseberg
Copy link
Collaborator

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.

@FredrikOseberg FredrikOseberg self-assigned this May 24, 2024
@FredrikOseberg FredrikOseberg moved this from New to In Progress in Issues and PRs May 24, 2024
@andretibolaintelipost
Copy link
Author

andretibolaintelipost commented May 24, 2024

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 new UnleashClientProviderWrapper creates a UnleashClient instance, and thats when all 3 instances write to the same Local Storage key

@kwasniew
Copy link
Contributor

kwasniew commented Aug 6, 2024

@andretibolaintelipost this PR should fix your issue: #225
Can you confirm if it's what you'd expect?

@github-project-automation github-project-automation bot moved this from In Progress to Done in Issues and PRs Aug 6, 2024
@andretibolaintelipost
Copy link
Author

Yes, this will definitely work in my use case. Thanks!!

@kwasniew
Copy link
Contributor

kwasniew commented Aug 7, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants