unleash-proxy-client-js icon indicating copy to clipboard operation
unleash-proxy-client-js copied to clipboard

Working with multiple UnleashClient instances

Open andretibolaintelipost opened this issue 1 year ago • 2 comments

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

andretibolaintelipost avatar May 23 '24 12:05 andretibolaintelipost

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 avatar May 24 '24 07:05 FredrikOseberg

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

andretibolaintelipost avatar May 24 '24 10:05 andretibolaintelipost

@andretibolaintelipost this PR should fix your issue: https://github.com/Unleash/unleash-proxy-client-js/pull/225 Can you confirm if it's what you'd expect?

kwasniew avatar Aug 06 '24 09:08 kwasniew

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

andretibolaintelipost avatar Aug 06 '24 12:08 andretibolaintelipost

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.

kwasniew avatar Aug 07 '24 07:08 kwasniew