$customHeader
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Today, we do not have a central data store. All of our MFEs have been built without such a capability, and so we currently have no active use cases for it in our current functionality. This is by way of saying that any usage of a central data store will be net new product or platform features, and we haven’t gathered requirements yet on what those could be.

The short answer could be, simply, “no, we don’t need a central data store.” At least at first.

That said, for the purposes of this document, we’ll imagine some possible use cases, and will take for granted that having inter-MFE communication and data sharing will be an enabling capability that will open up possibilities for new extensions and innovations.

There are a few kinds of data sharing we can envision:

Configuration

Today, each MFE loads its own configuration document (either through build-time or runtime config). Much of the config values in these are the same across MFEs, and it’d make sense for them to be defined and made available in one centralized place owned by the shell application.

Global State

Eventing

  • No labels