Techniques for cross micro frontend communication

An eCommerce site is extremely data rich; from search to store, to cart, to pricing, there are many facets that need to be managed effectively. Moreover, in an age of personalization and with users expecting fast and frictionless experiences, it’s important to ensure that this sophisticated web of moving parts and different sets of data can all work together seamlessly. 

It’s possible to achieve this with a monolithic architecture, but it does pose some challenges. Because the various aspects that make up your eCommerce site — like, for example, your cart and catalog — all sit inside the same app, when it comes to scaling or amending your application it can take considerable development time (and money). This means that while it might let you deliver a decent basic experience for your customers, achieving the level of quality you want — and your customers likely expect — can be very difficult. 

This is one reason why the engineering teams around the world are moving away from monolithic architecture and towards micro frontends. Micro frontends are, not unlike microservices, modular — they are isolated frontends for particular domains (like your catalog or cart) which can be built and deployed independently than the rest of the application and makes customization and optimization easier than they would be in a monolithic context. 

But micro frontends aren’t without challenges. While modularity can be an advantage, it also means you need to do a little more work to get the different parts — in this case different micro frontends — to talk to one another. 

There’s not a single solution for doing this. In this blog post we’ll look at a number of different ways to get micro frontends to talk to one another, and explore which is most effective for different scenarios and contexts. 

Please note that the code snippets added in the article are for example purpose only and might need some tweaks before running.

Using props

Passing properties as attributes — known as props — in component-based architecture is the most basic technique for cross micro frontend communication, where the container app is maintaining the state and passing it to the required micro frontends.

Consider the example of an eCommerce site with a micro frontends for its catalog and its cart. Here the catalog micro frontend would take a callback to add a product to the cart. This is responsible for increasing the total count and passing the count further to the cart micro frontend.

import {Catalog} from "@mfe/catalog";

import {Cart} from "@mfe/cart";

const App = () => {

  const [productsInCartCount, setProductsInCartCount] = useState(0);

  const addToCart = () => {

    setProductsInCartCount(productsInCartCount + 1);

  }

  return (

    <>

      <Catalog onAddToCart={addToCart} />

      <Cart productsCount={productsInCartCount} />

    </>

  )

}

The technique is effective in case of build time micro frontend integration pattern as it is a component-based architecture, which passes the data. 

Using platform storage APIs

In this technique, we can leverage the platform's built-in storage APIs like Local Storage in browsers and Async Storage in cross-platform solutions like react Native for mobile micro frontends too.

We can create a simple storage utility library exposing setter and getter from storage APIs. Now, instead of making micro frontends communicate via the container app, each micro frontend can set as well as read the data directly. 

Returning to the example of the catalog and cart, both the micro frontends are consuming the storage utility library. The catalog micro frontend is setting the latest count of added products in the storage, which is then read by the cart micro frontend.

// storage util

const storage = {

  getItem: (item) => {

    JSON.parse(localStorage.getItem(item));

  }

  setItem: (item, value) => {

    JSON.stringify(localStorage.setItem(item, value));

  }

}

// Catalog MFE

import {storage} from "@mfe-utils";

const Catalog = () => {

  const addToCart = () => {    

    const productsInCartCount =   storage.getItem('productsInCartCount');

    storage.setItem('productsInCartCount', productsInCartCount + 1);

  }

  return (

    <Product onAddToCart={addToCart} />

  )

}

// Cart MFE

import {storage} from "@mfe-utils";

const Cart = () => {

  const productsInCartCount = storage.getItem('productsInCartCount');

  return (

    <NumberOfProductsAdded count={productsInCartCount} />

  )

};

This technique can work for build as well as runtime integration of micro frontends. Since the storage APIs provided by different platforms do not follow the subscription pattern, the micro frontend will not immediately read the new data when it is updated by the other micro frontend. So, an asynchronous and pub sub model needs to be built. The technique will be more useful when two micro frontends are rendered in two different screens as the reader can fetch the updated data on the mount itself.

Using custom events

This technique is suitable for web micro frontends and is scalable for runtime micro frontends. The main idea here is to use the browser’s in-built custom event APIs to publish events with the data from one micro frontend. The other micro frontends subscribe to the events to get the data. This approach technique is very similar to events-driven architecture in the microservices world.

In the catalog and cart example, both micro frontends are consuming the event library. The catalog micro frontend creates an event ADD_TO_CART in the event registry and then publishes it. The cart micro frontend subscribes to the same event and receives the count of updated products in the cart via event data. When using this technique, we also need to ensure the events subscribed to are unsubscribed once the component is unmounted.

// Catalog MFE

const Catalog = () => {

  // fetch initial count first

  const [productsInCartCount, setProductsInCartCount] = useState(initialCount || 0);

  const addToCart = () => {     

    const addToCartEvent = new CustomEvent('ADD_TO_CART', { detail: { count: productsInCartCount + 1 } });

    window.dispatchEvent(addToCartEvent);

  }

  return (

    <Product onAddToCart={addToCart} />

  )

}

// Cart MFE

const Cart = () => {

  // fetch initial count first

  const [productsInCartCount, setProductsInCartCount] = useState(initialCount || 0);

  useEffect(() => {

    const listener = ({ detail }) => {

      setProductsInCartCount(detail.count);

    }

    window.addEventListener('ADD_TO_CART', listener)

    return () => {

      event.unsubscribe('ADD_TO_CART', listener);

    }

  }, []);

  return (

    <NumberOfProductsAdded count={productsInCartCount} />

  )

};

This technique can also work for build time as well as runtime integration of micro frontends. It can work even more effectively if cross-communication is done within the same page, as events need to be subscribed to before they are published.

Using a custom message bus

This technique is very similar to the one above, but instead of relying on the browser’s custom events API, we build our own pub-sub mechanism.

The message bus library can expose methods to publish, subscribe to, and unsubscribe from events. The publish event needs to make sure that all the subscribed handlers are invoked once the event is published.

In the  catalog and cart example, both the micro frontends consume the message bus library instance that is passed by the container app. The catalog micro frontend can then publish an event ADD_TO_CART, which the cart micro frontend will be subscribed to using the same message bus.

// Message bus library

class MessageBus {

  private publishedEventRegistry = {};

  publishEvent(eventName, data) {

    const registeredEvent = this.publishedEventRegistry[eventName];

    this.publishedEventRegistry = {

      ...this.publishedEventRegistry,

      [eventName]: {

        ...registeredEvent,

        name: eventName,

        data: data

      }

    };

    this.publishedEventRegistry[eventName].handlers.forEach(handler => {

      handler(this.publishedEventRegistry[eventName].data);

    });

  }

  subscribeEvent(eventName, handler) {

    const registeredEvent = this.publishedEventRegistry[eventName];

    this.publishedEventRegistry = {

      ...this.publishedEventRegistry,

      [eventName]: {

        ...registeredEvent,

        name: eventName,

        handlers: [...registeredEvent.handlers, handler]

      }

    };

  }

  unsubscribe(eventName) {

    this.publishedEventRegistry = {

      ...this.publishedEventRegistry,

      [eventName]: undefined

    }

  }

}

// App.js

import {Catalog} from "@mfe/catalog";

import {Cart} from "@mfe/cart";

import {MessageBus} from "@mfe-message-bus";

cont App = () => {

  const messageBus = new MessageBus();

  return (

    <>

      <Catalog messageBus={messageBus} />

      <Cart messageBus={messageBus} />

    </>

  )  

}

// Catalog MFE

const Catalog = ({ messageBus }) => {

  const addToCart = () => {    

    // get initial count first

    const [productsInCartCount, setProductsInCartCount] = useState(initialCount || 0);

    messageBus.publishEvent('ADD_TO_CART', { count: productsInCartCount + 1 });

  }

  return (

    <Product onAddToCart={addToCart} />

  )

}

// Cart MFE

const Cart = ({ messageBus }) => {

  // get initial count first

  const [productsInCartCount, setProductsInCartCount] = useState(initialCount || 0);

  useEffect(() => {

    const listener = (event) => {

      setProductsInCartCount(event.data.count);

    }

    messageBus.subscribeEvent('ADD_TO_CART', listener);

    return () => {

      messageBus.unsubscribeEvent('ADD_TO_CART', listener);

    }

  }, []);

  return (

    <NumberOfProductsAdded count={productsInCartCount} />

  )

};

This technique can be useful for build-time integration in the case of mobile micro frontends where there is no concept of custom events. It is important to ensure that all micro frontends are using the same instance of the message bus because an application should have only one registry for all the events published.

The choice of a particular mechanism doesn’t just depend on the micro frontend integration pattern (build time or run time) but also on the state of the project. For instance, you might not want to set the whole message bus system for an MVP as it has a huge setup cost with it. Ultimately, the best approach is to start simple and build on top of that as the project grows.

To find out more about micro frontends, take a look at our webinar series from 2022.