Micro-Frontends
Micro-frontends extend microservice principles to the frontend by decomposing a web application into smaller, independent applications that are developed, tested, and deployed by separate teams, then composed into a cohesive user experience.
§ 1 Definition
Micro-frontends are an architectural pattern where a frontend application is split into semi-independent fragments (micro-frontends), each owned by a dedicated team that can develop, test, deploy, and maintain its piece independently. Each micro-frontend can use its own framework, have its own CI/CD pipeline, and be deployed independently without coordination with other teams. The fragments are composed at runtime (or build time) into a single cohesive application visible to the user. This pattern addresses the scalability problems that arise when multiple teams work on a single monolithic frontend: dependency conflicts, coordinated deployments, merge conflicts, and scaling the development process. Micro-frontends are best suited for large enterprise applications with multiple autonomous teams. For smaller teams, the operational complexity of micro-frontends exceeds the benefits.
§ 2 Integration Approaches
Micro-frontends integrate through three main approaches. Client-side composition uses a shell application that loads micro-frontend bundles at runtime. Module Federation (Webpack 5) allows independently deployed applications to share components and dependencies dynamically. Server-side composition assembles HTML fragments from different services on the server before sending to the browser. Iframes are also used but come with severe UX and performance penalties. The choice of integration strategy affects performance, team autonomy, and user experience.
§ 3 Shared Concerns and Governance
Successful micro-frontend architectures require shared infrastructure for authentication, routing, design system, and inter-application communication. Teams must agree on a routing strategy (which micro-frontend owns which URL paths), state sharing (custom events, shared stores, or URL-based communication), and design consistency (a shared design system via Web Components is the most common solution). Without governance, micro-frontends produce a disjointed user experience with inconsistent navigation, styling, and behavior.
§ 4 Note
§ 5 Common questions
- Q. When should we adopt micro-frontends?
- A. When you have 3+ independent teams working on the same frontend application, each team has a distinct domain, and the coordination overhead of a monolith is causing missed deadlines. For fewer than 20 frontend developers, the complexity is rarely worth it.
- Q. Can each micro-frontend use a different framework?
- A. Technically yes, but practically you should limit to 1-2 frameworks. Each framework loaded adds JavaScript bundle overhead. Most successful implementations use one primary framework with Web Components for shared elements.
- Micro-frontends decompose a frontend into independent applications owned by separate teams with independent deployability.
- Integration approaches include Module Federation, runtime composition, and server-side assembly.
- Micro-frontends add significant operational complexity. Only adopt when team scale genuinely demands it.
Atomic Glue architects micro-frontend solutions for enterprise clients whose team scale demands independent deployability. We design the integration layer, establish governance for shared design systems and routing, and implement Module Federation or runtime composition strategies. Our approach prioritizes performance optimization through shared dependency management and progressive loading. If you are evaluating micro-frontends for your organization, we can help you assess whether the complexity is justified. This is part of our website development architecture consulting.
Get in touchMicro-frontends extend microservice principles to the frontend by decomposing a web application into smaller, independent applications that are developed, tested, and deployed by separate teams, then composed into a cohesive user experience.
Category: Front End (also: Software Engineering, Architecture)
Author: Atomic Glue Development Team
## Definition
Micro-frontends are an architectural pattern where a frontend application is split into semi-independent fragments (micro-frontends), each owned by a dedicated team that can develop, test, deploy, and maintain its piece independently. Each micro-frontend can use its own framework, have its own CI/CD pipeline, and be deployed independently without coordination with other teams. The fragments are composed at runtime (or build time) into a single cohesive application visible to the user. This pattern addresses the scalability problems that arise when multiple teams work on a single monolithic frontend: dependency conflicts, coordinated deployments, merge conflicts, and scaling the development process. Micro-frontends are best suited for large enterprise applications with multiple autonomous teams. For smaller teams, the operational complexity of micro-frontends exceeds the benefits.
## Integration Approaches
Micro-frontends integrate through three main approaches. Client-side composition uses a shell application that loads micro-frontend bundles at runtime. Module Federation (Webpack 5) allows independently deployed applications to share components and dependencies dynamically. Server-side composition assembles HTML fragments from different services on the server before sending to the browser. Iframes are also used but come with severe UX and performance penalties. The choice of integration strategy affects performance, team autonomy, and user experience.
## Shared Concerns and Governance
Successful micro-frontend architectures require shared infrastructure for authentication, routing, design system, and inter-application communication. Teams must agree on a routing strategy (which micro-frontend owns which URL paths), state sharing (custom events, shared stores, or URL-based communication), and design consistency (a shared design system via Web Components is the most common solution). Without governance, micro-frontends produce a disjointed user experience with inconsistent navigation, styling, and behavior.
## Note
Common misunderstanding: Micro-frontends are not a solution for team structure problems. Conway's Law states that organizations design systems that mirror their communication structure. If your teams cannot coordinate on a monolithic frontend, micro-frontends will not fix that. They make coordination harder in some ways. Another misconception: micro-frontends solve performance problems. They almost always make performance worse by duplicating framework instances and dependencies across micro-frontends. Proper code sharing and Module Federation optimization are essential.
## Common questions
Q: When should we adopt micro-frontends?
A: When you have 3+ independent teams working on the same frontend application, each team has a distinct domain, and the coordination overhead of a monolith is causing missed deadlines. For fewer than 20 frontend developers, the complexity is rarely worth it.
Q: Can each micro-frontend use a different framework?
A: Technically yes, but practically you should limit to 1-2 frameworks. Each framework loaded adds JavaScript bundle overhead. Most successful implementations use one primary framework with Web Components for shared elements.
## Key takeaways
- Micro-frontends decompose a frontend into independent applications owned by separate teams with independent deployability.
- Integration approaches include Module Federation, runtime composition, and server-side assembly.
- Micro-frontends add significant operational complexity. Only adopt when team scale genuinely demands it.
## Related entries
- [Web Components](atomicglue.co/glossary/web-components)
- [Single Page Application (SPA)](atomicglue.co/glossary/single-page-application-spa)
Last updated June 2026. Permalink: atomicglue.co/glossary/micro-frontends