Micro-Frontend

The foundational principle of micro-frontends. Each micro-frontend is an autonomous unit that can be built, tested, and deployed to production on its own release cycle without coordinating with other teams. This is achieved by encapsulating the entire vertical slice—from UI to API calls—within a single team's ownership. A change to a shopping cart feature should never require rebuilding the product listing page. This independence is enforced through contract testing and strict API versioning between the host application and its fragments.

Each micro-frontend team is free to choose its own technology stack—React, Vue, Svelte, or even vanilla JavaScript—without affecting other teams. This avoids the lock-in of a single framework and allows gradual migration. The host application, often called the app shell, remains framework-agnostic by loading each micro-frontend as a black box. This is typically implemented via Module Federation in Webpack or native ES modules with import maps, ensuring that shared dependencies like React are deduplicated at runtime to avoid bundle bloat.

A JavaScript error in one micro-frontend must not crash the entire application. This is enforced through error boundaries and strict encapsulation. Each fragment runs in its own isolated scope, often using Shadow DOM or iframes for CSS containment, preventing style leaks. If the 'Product Reviews' micro-frontend fails to load, the rest of the page remains functional. This resilience is critical for large-scale e-commerce platforms where a single point of failure in a monolithic frontend can halt all revenue.

Micro-frontends align team structure with business capabilities, not technical layers. A single team owns the end-to-end feature—from the database to the pixel. This eliminates cross-team dependencies for UI development. For example, the 'Checkout' team owns the checkout micro-frontend, its backend-for-frontend (BFF) API, and its data store. This structure, known as Conway's Law in action, reduces communication overhead and enables teams to deliver features faster without waiting for a shared UI layer team.

Unlike build-time integration, micro-frontends are assembled in the browser at runtime. The app shell fetches each micro-frontend's manifest and renders it into a designated slot. Composition strategies include:

• Client-side composition: The shell uses JavaScript to mount fragments.
• Edge-side composition: A CDN stitches fragments together using Edge-Side Includes (ESI).
• Server-side composition: A Node.js service assembles the page from fragments before sending HTML. This runtime approach allows for dynamic A/B testing and feature flagging without redeploying the shell.

Micro-frontends communicate through well-defined, versioned contracts, not shared global state. A shared event bus using Custom DOM Events or a lightweight pub/sub library allows decoupled communication. For cross-cutting concerns like authentication, a shared Web Component or a dedicated service provides the user session. The critical rule is to avoid a shared component library that forces all teams to upgrade simultaneously; instead, use Module Federation to share dependencies at runtime with strict version negotiation.

A server-side or edge-side pattern where a final user interface is assembled by aggregating rendered fragments from multiple, independent microservices or templates. Unlike client-side composition, this approach resolves the distinct fragments at the CDN or server layer before the HTML reaches the browser. This is critical for performance, as it prevents client-side layout shifts and reduces the JavaScript burden on the user's device.

A performance optimization technique that breaks a large JavaScript bundle into smaller chunks which can be loaded on demand or in parallel. In a micro-frontend architecture, effective code splitting is essential to prevent users from downloading the entire application codebase upfront. It ensures that the browser only fetches the specific feature bundles required for the current view, maintaining fast initial load times.

The process where a JavaScript framework attaches event handlers and state to server-rendered HTML in the browser, making a static page interactive. Micro-frontends must carefully manage hydration to avoid conflicts. Techniques like progressive hydration or using frameworks that support islands architecture allow individual micro-frontends to become interactive independently without blocking the main thread.