Glossary

This glossary defines key terms used in micro frontend architecture and related disciplines. Each term includes a concise definition and links to relevant pages where the concept is explored in depth.

Terms

Micro Frontend

A self-contained slice of a user interface that encapsulates a vertical business capability, can be developed and deployed independently, and is composed with other micro frontends to form the full application. Micro frontends extend microservices principles to the frontend layer. See What Are Micro Frontends? for a full treatment.

Application Shell

The host application that loads first and provides the layout, routing, and orchestration logic. The shell defines slots where micro frontends mount and coordinates their loading and lifecycle. It typically owns the header, footer, and navigation while delegating main content to MFs. Covered in Composition Strategies.

Composition (Client-Side, Server-Side, Edge-Side)

The act of assembling multiple micro frontends into a coherent user experience. Client-side composition loads and mounts MFs in the browser. Server-side composition assembles HTML on the server before sending to the client. Edge-side composition runs at the CDN edge for low latency. Each approach has distinct trade-offs in performance, SEO, and complexity. See Composition Strategies.

Module Federation

A Webpack 5 (and Rspack) feature that enables runtime code sharing between independently built applications. A host consumes modules from remotes at runtime without a single unified build. Used to share React, utilities, and design systems across micro frontends. Deep dive: Module Federation.

Host Application

In Module Federation and similar setups, the application that loads first and acts as the container. The host imports and renders modules exposed by remote applications. Often synonymous with the application shell in a micro frontend architecture.

Remote Application

An application that exposes modules, components, or chunks for consumption by a host at runtime. In Module Federation, remotes are independently built and deployed; the host loads them on demand. Each micro frontend can be implemented as a remote.

Shared Dependencies

Libraries or packages used by multiple micro frontends (e.g., React, design system, date utilities). Sharing them—via a common bundle, Module Federation, or Import Maps—reduces duplicate code and improves caching. See Shared Dependencies for deduplication strategies.

Import Maps

A browser-native mechanism to map bare module specifiers (e.g., "react") to URLs. Allows the browser to resolve and load ES modules without a bundler. Useful for sharing dependencies across micro frontends in development or controlled production environments. Learn more in Tools and Frameworks.

Web Components

A set of native browser APIs: Custom Elements, Shadow DOM, and HTML Templates. Web Components are framework-agnostic and provide encapsulation and reusability. Micro frontends can expose Web Components for composition in any host environment. See Tools and Frameworks.

Shadow DOM

A DOM tree that is encapsulated from the main document. Styles and markup inside Shadow DOM do not leak out, and external styles do not leak in. Used with Custom Elements to create self-contained components. Part of the Web Components standard.

Custom Elements

A browser API for defining new HTML elements with custom behavior and lifecycle. Custom Elements register new tag names (e.g., <my-button>) that behave like native elements. Often used with Shadow DOM to build reusable, encapsulated components for micro frontend composition.

Single-SPA

A meta-framework for composing multiple frontend frameworks (React, Vue, Angular, etc.) in one application. Single-SPA handles routing and lifecycle (mount/unmount) while each micro frontend remains framework-specific. See Tools and Frameworks.

Parcels (Single-SPA Concept)

In Single-SPA, a parcel is a smaller unit than a full application—a reusable piece of UI that can be mounted in multiple places. Parcels share the same lifecycle (bootstrap, mount, unmount) as applications but are more granular. Useful for shared widgets (cart, user menu) across routes.

Vertical Slicing

Organizing work and architecture by business capability (e.g., product catalog, checkout) rather than by technical layer (UI, API, database). Each vertical slice is owned end-to-end by a team. Micro frontends align with vertical slicing—each MF is a vertical slice. Related to Domain-Driven Design.

Domain-Driven Design (DDD)

A software design approach that models the domain explicitly and aligns code structure with business boundaries. DDD concepts—bounded contexts, aggregates, ubiquitous language—inform how micro frontends and microservices are partitioned. Vertical slicing in MFs often reflects DDD boundaries.

Conway’s Law

The observation that system architecture tends to mirror communication structures of the organization that builds it. If teams are siloed, the system becomes siloed; if teams are cross-functional and domain-aligned, the system can be modular and domain-aligned. Micro frontends are often adopted to align architecture with team structure.

Contract Testing

Testing the contract between a consumer and a provider without running the full system. In micro frontends, contract tests verify that MF-to-MF or MF-to-API interfaces remain compatible across independent deployments. Tools like Pact support this. See Tools and Frameworks for Pact.

Independent Deployment

The ability to deploy a micro frontend without deploying the entire application or coordinating with other teams. Each MF has its own release pipeline, version, and rollout strategy. A core benefit of micro frontend architecture; see Deployment Strategies for practices.

Feature Flags

A mechanism to enable or disable features at runtime without deploying new code. Used in micro frontends to gradually roll out new MFs, A/B test variations, or disable problematic MFs without a full rollback. Complements independent deployment.

Design System

A collection of reusable components, patterns, and guidelines that ensure visual and interaction consistency across an application. Micro frontends often consume a shared design system so the composed experience feels unified. Can be distributed via npm, Module Federation, or Web Components.

Monorepo

A version-control strategy where multiple packages or projects live in a single repository. Micro frontends can be developed in a monorepo for simpler dependency management and atomic changes, or in separate repos (polyrepo) for stronger isolation. Monorepos do not imply micro frontends—they are orthogonal.

Polyrepo

A version-control strategy where each project or team has its own repository. Micro frontends in a polyrepo are fully isolated at the code level; integration happens at build or runtime. Suited for strongly independent teams; requires careful dependency and version management.

Blue-Green Deployment

A deployment strategy where two identical environments (blue and green) exist; traffic is switched from one to the other atomically. Used for zero-downtime releases. Applicable to micro frontend deployments when the shell or CDN routes traffic between versions.

Canary Release

A gradual rollout where a small percentage of traffic receives the new version while the rest receives the old. Used to validate changes before full rollout. Micro frontends can be canary-released independently—e.g., 5% of users see the new checkout MF before it goes to 100%.

Go Deeper in the Book

Get the complete guide with detailed examples, diagrams, and production-ready patterns in Micro Frontends Architecture for Scalable Applications.