Protecting domains for singleton-based SDKs w/ provider + context freezing

[MattIPv4]

👋 Pulling this out of a discussion on Slack:

I'm working with the web SDK in a microfrontend world, which notably uses a singleton approach on window. We've recently run into an issue where the core of the frontend is using the default domain for its OpenFeature usage, but then a microfrontend that was written by another team (or conceivably even an external third-party writing a frontend plugin) accidentally also used the default domain for their OpenFeature usage and, due to the global singleton nature of the web SKD, overwrote the provider + context that the frontend core had set.

One option is potentially to allow for the global singleton behaviour to be opted out of, so that each microfrontend using OpenFeature creates a new instance of the SDK. While, on the surface, this does work to ensure that a microfrontend can't interfere with the frontend core, or another microfrontend, it also means that we can't allow microfrontends to rely on the default domain if they just want to read the flags that the frontend core has already evaluated -- we just want to prevent mutations of the default domain, while allowing reads still. Opting out of the singleton behaviour would also be something that only the frontend core itself could do, but it wouldn't be able to enforce it on the microfrontends, so there is still a risk two microfrontends both use the default domain and collide with each other.

So, the idea I'm proposing as a solution to this is a concept of allowing a domain's provider and/or context to be frozen within the SDK, preventing mutations of those:

enum FrozenStatus {
  Thawed = 0,  // Allows for a simple truthy check to know if frozen or not
  Silent = 1,  // Silently drops any attempt to mutate a provider/context
  Log    = 2,  // Logs a warning when a mutation attempt occurs
  Throw  = 3,  // Throws a runtime error when a mutation attempt occurs
}

OpenFeature.freezeProvider(domain?: string, status?: FrozenStatus = FrozenStatus.Throw);
OpenFeature.isFrozenProvider(domain?: string): FrozenStatus;

OpenFeature.freezeContext(domain?: string, status?: FrozenStatus = FrozenStatus.Throw);
OpenFeature.isFrozenContext(domain?: string): FrozenStatus;

With these in place, the SDK can keep track of which domains (including the default) have what frozen status for their provider + context, similar to the map it currently maintains of the providers themselves. It can then check against the map when the OpenFeature.setProvider, OpenFeature.setContext, OpenFeature.clearContext, etc., methods are used to know if a mutation should be allowed.

As a very rudimentary version of this, I put together https://github.com/grafana/grafana/pull/112515/files as a monkey-patch to the web SDK for our specific usage to try out what it'd look like to prevent mutations of the default domain's provider and context. Hopefully that helps visualise what this idea looks like / is trying to achieve.

[toddbaert]

@MattIPv4 some clarification to confirm my understanding:

If the "core" frontend is the only one that sets a provider for the root domain, and all the "micro/plugin" frontends (let's imagine one called "notifications" for this discussion) use only a domain that belongs to them (ie: OpenFeature.setProvider('notifications'), then:

var notificationsFlags = OpenFeature.getClient('notificiations')  // this will work with the micro-frontends flags
var coreFlags = OpenFeature.getClient() // this will work with the "core" flags

In this case, the micro-UI can access both flag sets (though they do have to have some knowledge about which client to use).
Is this satisfactory?
Are you simply worried that a micro-frontend "accidentally" mutates the root provider?

[MattIPv4]

Are you simply worried that a micro-frontend "accidentally" mutates the root provider?

Yes, exactly. Our guidance to the microfrontends is already to make sure they're using a custom domain if they need their own provider/context, but we still ended up with a microfrontend being shipped that was accidentally using the default domain to set their own provider/context. So, I'd quite like something that the frontend core can do that actually protects its usage (while still allowing the microfrontends read-only access to it).

[beeme1mr]

Does your root domain need to worry about updating context?

[MattIPv4]

I don't think it will, no, I think it will set it once on boot, and then ideally freeze it.

[jonathannorris]

@MattIPv4 I need to think through this more. I understand the issue here, but I don't think this is the correct path forward as it pretty fundamentally changes some of the root SDK behaviours.

What front-end framework are you using? I'm wondering if there is something more native to the front-end framework / React that we could implement to achieve the same behaviour.

[MattIPv4]

👍 I think that mostly works, and would be a good compromise here, though if we were to have an somewhere in the React tree above the plugin/microfrontends, they'd still be able to call useContextMutator and potentially mutate the core's context, even if it were using a symbol for its domain?

[beeme1mr]

still be able to call useContextMutator and potentially mutate the core's context, even if it were using a symbol for its domain?

I think that's the biggest challenge. It's easy to say "don't do that," but in reality, that's easier said than done. I wonder if a lint rule could be created to flag potential misuse.

[MattIPv4]

Yeh, saying don't do that and even having a lint rule that's a default across our stacks helps, but it doesn't really guarantee it (not everyone uses the shared lint defaults etc.), and for third-party plugin developers as well.

[lukas-reining]

I need to think through this more. I understand the issue here, but I don't think this is the correct path forward as it pretty fundamentally changes some of the root SDK behaviours.

What exactly do you mean by this @jonathannorris?

changes some of the root SDK behaviours

In my view it just adds another behavior that you explicitly opt-in to. This would not concern me too much.

What front-end framework are you using? I'm wondering if there is something more native to the front-end framework / React that we could implement to achieve the same behaviour.

Looking at different modularization libraries or MF approaches, I think this would be hard to solve.
single-spa, webpack module federation/module federation or simple client/server side includes provide very different ways and levels of isolation and mechanisms.

[jonathannorris]

@lukas-reining, my main concern is that optional functionality creep that affects the SDK's core behaviour will carry a very high maintenance burden going forward. I've made many mistakes over the years extending the start options of SDKs that change the core logic of the SDKs. Over time, this causes functionality bugs and requires rigorous testing to ensure it stays working over years for a very small percentage of use cases.

If we can find a way that just extends or wraps the existing behaviour of the SDKs without implementing this freeze / unfreeze concept within the core of the SDKs I think that would be a better approach long-term.

[lukas-reining]

I get the idea and understand, that even though you can use domains to separate providers, this does not prevent the accidental overwrites you describe @MattIPv4.
I am a bit worried, that the frozen status could be relatively complicated for something that most apps do not use.
On the other hand, this would be a totally optional feature which can be ignored in most cases.

One question I have is about unfreezing. If the different micro frontends would freeze and unfreeze their specific providers, weird situations could still occur when e.g. one micro frontend loads first, sets freezes the "wrong" domain and another one initializes and fails. In the other hand, this would at least be visible pretty early and probably latest during development or integration.
So for MFs I think this is especially useful.

[MattIPv4]

Yes, I think you're exactly right with the potential collisions with freezing/unfreezing, essentially the same collisions this is trying to solve with the "standard" methods of the SDK. I'd hope that a frozen status would be a bit more visible during development and testing, as you note, and I'd also hope that if you're doing freezing/unfreezing, that'll prompt developers to think a bit more about what they're doing -- it feels like an advanced usage feature.

[lukas-reining]

Yeah that makes sense. After my initial thought I think seeing the collisions early really is a benefit.

essentially the same collisions this is trying to solve with the "standard" methods of the SDK

Exactly and having people aware by event doing the freezing seems convincing to me.

it feels like an advanced usage feature.

Definitely, and I think most will not need it. I think MFs are really one of the use cases where this can be important. Maybe the same counts for "modular monoliths" or something like hexagonal architecture on the server side.