What’s so special about microfrontends?

What you see below is a hotel image gallery, built as a 6M microfrontend.

You might think: “What’s so special about an image gallery? Didn’t we have those for, like, 20 years now?”

The difference between a microfrontend and a traditional image gallery is that you can simply pass the hotel ID to the microfrontend, and it will retrieve images and meta data from an API itself, while the plain old gallery will need the host page to retrieve and inject the data.

In fact, all you need to display the hotel gallery on any webpage, is the following code. Try it out!

<script src="https://cloud.tui.com/6m/beone-content/hotel-gallery-6m/master/main.js" async defer></script>
<div style="height: 500px; max-width: 800px"> <!-- This is just a container to give the gallery some space -->
    <tui-hotel-gallery product-code="GPA10011"></tui-hotel-gallery> <!-- insert the product code of any hotel -->
</div>

Data Flow Differences

The following comparison shows the steps that will be performed to display images in either scenario.

Traditional UI component	Microfrontend component
Host page → embeds gallery component Host page → retrieves hotel data by ID Host page → formulates data structure as expected by gallery component Gallery Component → displays images + data	Host page → embeds gallery component Gallery Component → reads the hotel ID Gallery Component → retrieves hotel data Gallery Component → displays images + data

The differences may seem trivial, but they’re not. The implication is that the microfrontend has almost no dependencies on its environment. The webpage on which the microfrontend image gallery is embedded neither needs to know about any APIs and the data they provide, nor does it need to care about the lifecycle of the gallery component. At the same time, the traditional gallery needs the environment to retrieve and provide the correct information from an API. And, god forbid that the data API or the data requiements of the gallery change at some point in time. But this never happens, right?

Terminology: “Component” vs. “Component”

The difference becomes even more apparent when we look at the platform architectures of both scenarios. While you couldn’t guess the difference between a UI and a microfrontend component just by looking at the user interface, it will help to look at the technology stack to understand the difference between the different concepts of a “component”:

Traditional UI component	Microfrontend component
A traditional component only implements user interface aspects. It does not solve other frontend (state, API, etc.) or even backend aspects. It is tightly coupled to a specific frontend framework, such as React or Angular. It is usually developed as part of the frontend backlog.	A 6M microfrontend component contains all frontend and backend functionality. It is loosely coupled to other frontend parts, and each one can be written using a different framework. A 6M component usually has its own backlog and requires a broad skillset in the team.

As these approaches are literaly diametric to each other; the implications of this difference go far beyond technology. Read more about the concept of verticalization.