Micro-frontend architecture: patterns, tradeoffs, and implementation guide

Micro-frontends extend the microservice pattern to the frontend. Each team owns a distinct part of the UI, developed and deployed independently. When done well, micro-frontends enable team autonomy. When done poorly, they create a fragmented user experience.

There are several integration patterns. Iframe integration is the simplest but has poor UX. Web Component integration uses custom elements as the integration boundary. Module federation shares JavaScript modules across independently built applications at runtime.

Composition happens on the client or the server. Client-side composition loads each micro-frontend separately in the browser. Server-side composition assembles the HTML on the server before sending it to the client. This gives faster initial loads.

Shared dependencies are the hardest problem. Each micro-frontend might import a different version of React. Loading multiple versions duplicates code. Use module federation or import maps to share a single version of common dependencies.

UX consistency requires deliberate effort. Use a shared design system implemented in web components. Each micro-frontend uses the same button, form field, and navigation components. The design system enforces visual consistency.

Micro-frontends should not be your default. They add significant complexity and should only be adopted when justified by team scaling. For most applications, a well-structured monolith with clear module boundaries serves better.

If you adopt micro-frontends, invest heavily in shared infrastructure: the shell application, deployment pipeline, design system, and performance monitoring. The shared infrastructure makes the experience cohesive.

-

Rizwan Saleem | https://rizwansaleem.co