Introduction
In an ideal world, there will be no need to communicate between different micro-frontends, however, in the world where we live-in, there always be some cases where we need to communicate to share data between micro-frontends. But before we dive into the different ways of communicating between micro-frontends, let's take a step back and see on a high level what micro-frontend is.
Micro-frontend is an architectural pattern that advocates breaking down large monolithic frontend applications into smaller, more manageable, easily testable, and deployable applications. It draws inspiration from microservices architecture pattern for backend API.
Different Communication Ways
1. Custom Event
Especially useful in the case of horizontal-split architectural style micro-frontend (check out post for more details on Micro-frontend Decision Framework), as multiple micro-frontends share the same space in a single page view. A custom event is a regular event with a custom body, that provides the ability to define the event name and an optional custom object for the event. The custom event should be dispatched via a common object that is available to all micro-frontends, most likely that common object will be the browser's window object.
new CustomEvent('myCustomEvent', {detail: {customObj: "SomeData"}})
2. Cookies
The second option available to share data is cookies, some good use cases to share data via cookies are saving the user's setting to persist volume level or session token. Depending upon data security different flags on cookies can be set like secure, expire (shorter expiry time). Remember, data can only be shared when micro-frontends live under the same sub-domain.
3. Web-Storage
Another way to communicate between different micro-frontends is via web storage. Either session or local web storage can be used to share the data, it can be a good use case to store session tokens or less sensitive user data like user's preference. Similar to cookies, data can only be shared when micro-frontends live under the same sub-domain.
4. Query Parameter
It can be easily overlooked as an option to share data from micro-frontends but mind it, it's a good option with no complexity. Sometimes we need to follow principles like YAGNI (You Aren't Gonna Need It), KISS (Keep it simple, stupid!) to reduce complexity. It's a good option when we need to share data like item code, product code, etc.
https://www.samplesite.com/items/detail?id=007
Conclusion
There are various tools available to communicate or share data between different micro-frontends, however, as a developer we need to decide on when to use which tool. These decisions can be made based upon various factors like the type of micro-frontend architectural styles (horizontal-split vs vertical-split), data security (can it be stored on the frontend or backend) etc. (check out post for more details on Micro-frontend Decision Framework)
If you have reached here, then I made a satisfactory effort to keep you reading. Please be kind enough to leave any comments or ask for any corrections.
Top comments (0)