How Microfrontends Work: From iframes to Module Federation

Microfrontends are transforming how teams build and deploy frontend applications at scale. This tutorial explores the architectural landscape, from traditional approaches to modern Module Federation implementations. By the end, you'll be equipped to ...

May 31, 2025 - 03:30

How Microfrontends Work: From iframes to Module Federation

Microfrontends are transforming how teams build and deploy frontend applications at scale. This tutorial explores the architectural landscape, from traditional approaches to modern Module Federation implementations.

By the end, you'll be equipped to evaluate whether microfrontends are the right solution for your team's specific needs.

I’ll cover the following:

What are Microfrontends?

If you've heard about microservices on the backend, microfrontends represent a similar approach in the frontend world, with many of the same benefits.

Your team might adopt a microfrontend approach to enable team autonomy, reduce deployment risks, and scale development across multiple teams. Each team owns its technology stack, deployment cadence, and workflows. Yet they still deliver a single, cohesive user interface.

The overall idea is to move away from a big monolithic UI to decoupled UI codebases that can be owned, managed, and deployed by separate teams independently.

The simplest way to think about Microfrontends is the following:

Integrate one piece of UI into another

What can this piece of UI be, you may ask? Here are some examples:

Pages – parts of a website owned by specific teams. For example, the Auth team may own login/signup pages, whereas the engagement team may own the marketing pages, and so on.
Components – Components like header and footer are good candidates for a microfrontend approach as well. They’re relatively static but need to stay consistent across the website and may integrate with teams who own different sets of pages.
Widgets – A recommendation widget may be owned by a recommendations team, for example, and it can be integrated into different parts of the page based on the context. This is different from a static component, as given the context, the recommendation widget may also fetch relevant data via APIs (also owned by the recommendations teams).

Traditional Microfrontend Patterns

After reading the definition of a microfrontend, you might be thinking, oh, wait, who builds UI with a big monolith these days anyway (except giants like Google)? If that’s the case, your team is most likely using one of these traditional approaches to building Microfrontends:

Server-Side Composition

This is the most common approach I've encountered across various organisations. The idea is to split your website based on route patterns or pages. For example, you might route users to the accounts team for any routes starting with /account/* (/account/login or /account/signup may fall under this pattern). Or you may have a similar route prefix for other parts of your web app, like /blog/* for the marketing section of your app.

This is typically implemented at the reverse proxy layer (such as using NGINX), which routes traffic to the appropriate downstream UI service based on the path matching.

Diagram showing a reverse proxy setup with nginx. The proxy routes `/blog/*` requests to the Marketing UI and `/account/*` requests to the Accounts UI.

iframes

Another common approach is using iframes, though this method has significant limitations.