Composition Strategies

Composition is the foundational architectural decision in any micro frontend system. It determines how independently developed and deployed frontend applications are assembled into a unified user experience. The choice of composition strategy affects performance, developer experience, deployment flexibility, and organizational constraints.

Client-Side Composition

Client-side composition assembles micro frontends in the browser. The application shell loads and orchestrates remote micro frontends at runtime.

JavaScript-Based Composition

The most common approach. A shell application dynamically loads JavaScript bundles for each micro frontend and mounts them into designated DOM nodes.

// Shell application: dynamically importing a remote micro frontend
const container = document.getElementById('product-detail');
const { mount } = await import('https://cdn.example.com/product-mf/main.js');
mount(container, { productId: '123' });

Pros: Highly flexible, supports any framework, enables independent deployments. Cons: Requires careful orchestration, potential for runtime errors if a remote fails to load.

Web Components

Each micro frontend is packaged as a custom element. The shell simply uses standard HTML tags.

<product-detail product-id="123"></product-detail>
<shopping-cart></shopping-cart>

Web Components provide native browser encapsulation via Shadow DOM and work across frameworks. They are well-suited for design systems that span multiple micro frontends.

Iframe-Based Composition

Each micro frontend runs in its own iframe, providing the strongest isolation.

Pros: Complete CSS and JavaScript isolation, fault containment. Cons: Poor performance (each iframe is a separate browsing context), limited cross-frame communication, accessibility challenges, no shared layout.

Iframes are best suited for embedding third-party content or legacy applications where isolation is non-negotiable.

Server-Side Composition

Server-side composition assembles micro frontends on the server before sending HTML to the browser. This produces a complete page on first load, benefiting SEO and perceived performance.

Server-Side Includes (SSI)

A classic technique where the web server (Nginx, Apache) replaces include directives with content from upstream services.

<!--#include virtual="/fragments/header" -->
<main>
  <!--#include virtual="/fragments/product-detail?id=123" -->
</main>
<!--#include virtual="/fragments/footer" -->

Edge-Side Includes (ESI)

Similar to SSI, but executed at the CDN layer (Akamai, Varnish). ESI allows per-fragment caching — the header can be cached for an hour while the product detail is cached for five minutes.

<esi:include src="/fragments/product-detail?id=123" />

Layout Services

Frameworks like Podium and Tailor act as layout engines that fetch HTML fragments from micro frontend services and compose them into a full page.

Podium uses a manifest-based approach where each micro frontend (called a “podlet”) exposes a manifest describing its assets and markup endpoint. The layout server fetches and assembles them.

Benefits of server-side composition: Better SEO, faster First Contentful Paint, reduced client-side JavaScript. Trade-offs: More complex server infrastructure, harder to handle client-side interactivity between fragments.

Edge-Side Composition

A modern variation of server-side composition that runs at the CDN edge using workers (Cloudflare Workers, AWS Lambda@Edge, Vercel Edge Functions).

Edge composition combines the performance benefits of server-side rendering with global distribution:

Low latency: Composition happens close to the user.
No origin bottleneck: Edge workers scale independently.
Per-request personalization: Edge logic can route to different MF versions based on user context.

This approach is gaining traction as edge computing platforms mature.

Build-Time Composition

Micro frontends are composed during the build step rather than at runtime. Each micro frontend is published as an npm package, and a host application imports them as dependencies.

{
  "dependencies": {
    "@org/product-mf": "^2.1.0",
    "@org/cart-mf": "^1.5.0",
    "@org/checkout-mf": "^3.0.0"
  }
}

Pros: Simplest to reason about, great for performance (single optimized bundle), full type safety. Cons: Loses independent deployability — a change in any MF requires rebuilding and redeploying the host. Couples release cycles.

Build-time composition works well for small organizations or when the number of micro frontends is limited and release coordination is acceptable.

Comparison

Strategy	Independent Deploy	SEO	Performance	Isolation	Complexity
Client-side (JS)	Yes	Requires SSR	Good	Medium	Medium
Client-side (Web Components)	Yes	Requires SSR	Good	Strong	Medium
Client-side (iframes)	Yes	Poor	Poor	Strongest	Low
Server-side (SSI/ESI)	Yes	Excellent	Excellent	Low	Medium
Server-side (Layout services)	Yes	Excellent	Good	Medium	High
Edge-side	Yes	Excellent	Excellent	Medium	High
Build-time	No	Excellent	Best	None	Low

Choosing a Strategy

There is no universally best approach. The right choice depends on:

SEO requirements: If critical, lean toward server-side or edge composition.
Team autonomy needs: Client-side and server-side runtime approaches maximize independence.
Performance constraints: Build-time gives the best bundle optimization; edge gives the best latency.
Existing infrastructure: Server-side composition requires backend orchestration; edge requires CDN workers.

Most production systems use a hybrid approach — for example, server-side composition for the initial page load combined with client-side composition for dynamic in-page interactions.

Learn more about routing across composed micro frontends and how Module Federation enables runtime code sharing.

Go Deeper in the Book

This topic is covered in depth in Chapter 3 of Micro Frontends Architecture for Scalable Applications, with detailed examples, diagrams, and production-ready patterns.