The Myth of Microfrontend Isolation

What MFEs really guarantee (and what they don’t)

pc: https://www.vecteezy.com

If you are coming from ***Microfrontends: A Practical Mental Model*** and almost thought, “Wow! I’ll make this an MFE and throw my dependency issues to wind”, sorry to disappoint you. MFEs don’t have that magic in them.

MFE isolation is by design; not by implementation.

MFE as a concept requires you to design it and integrate it in such a way that, you don’t induce any dependency issue in your application. In fact, run time errors can spike in an MFE-heavy application (eg, in case the scope of the shared libraries like React, axios etc are not managed properly). There can be duplicate instances of shared libraries in the browser, leading to race conditions, inconsistent states etc across the Host application/ MFE consumer and the MFE itself.

Let’s see an example to understand this, without a deep-dive into the reasons.

Let’s go back to our e-commerce application example. The Header and the Catalogue MFEs would be sharing their states via some lightweight state management libraries like Redux or Zustand. The Cart already has some items added.

Let’s add 3 books and 1 compass to the cart. You’d see the catalogue’s counters getting updated, but the CartIcon in the header would not show any difference.

Try refreshing the page. Still, the states would be the same.

This is a classic case of state inconsistencies that can happen when MFE configuration is not proper. The MFE has not been designed to maintain consistent states across the application.

(To those curious, the problem above is:

shared state library duplicated → multiple instances → cart count mismatch.)

What comes under the design?

The design would absolutely include the components we create for each concept: Catalogue, Header, Cart etc.

But on top of that, for MFEs, we setup a Webpack Module Federation Configuration. This is basically, a contract between different MFEs, which communicate the:

1. Components to expose
2. Components to consume
3. Libraries to share
4. Libraries for the MFE

The Host also would need such a configuration. Even if the host is not itself an MFE, the configuration is important to let the host know which all MFEs it is consuming. Think of it like, you are renting out your house. The deals go through a broker, as you are staying abroad. The broker arranges the renters and tells them to which account they should be sending their rents to. But the broker also needs to send you the renters’ account details, so that the host knows where and who the rent is coming from and how much it is.

In the next post, we’ll have a mental model of Webpack. That would be our bridge to starting with MFE concepts. :)