Micro Frontends with Angular
5 questions found
What is a micro frontend architecture, and why might a large organization choose it for their Angular apps?
Intermediate
A micro frontend architecture splits a large web application into several smaller, independently developed and deployed applications, often owned by separate teams, that are then composed together into a single user experience. This lets large organizations scale development across many teams without everyone needing to coordinate releases of one single massive application.
// Conceptually, a shell app loads separate independently deployed applications
// Team A owns and deploys the 'checkout' micro frontend
// Team B owns and deploys the 'catalog' micro frontend
// Both are composed together into one seamless user experience
Real-world example
A large retail company splits their website into separate checkout, catalog, and account micro frontends, each owned and deployed independently by different teams, letting each team ship updates without waiting on the others.
Common follow-ups: What are the main challenges a team faces when adopting a micro frontend architecture?;How does this approach compare to simply using Angular's own lazy loaded feature modules?
NgModules & Modular Architecture;Angular Elements (Web Components)
How does Module Federation, a popular tool used with micro frontends, let separate Angular applications share code at runtime?
Advanced
Module Federation lets one application expose specific modules, and another completely separate application load and use those modules directly at runtime, without needing both to be built or deployed together, enabling truly independent applications to share components or services dynamically.
// webpack.config.js in the app exposing a module
new ModuleFederationPlugin({
name: 'catalog',
exposes: { './ProductList': './src/app/product-list/product-list.component.ts' }
});
// webpack.config.js in the app consuming it
new ModuleFederationPlugin({
remotes: { catalog: 'catalog@http://localhost:4201/remoteEntry.js' }
});
Real-world example
A shell application dynamically loads a completely separately deployed catalog micro frontend's product list component at runtime, using Module Federation, without the shell needing to be rebuilt whenever the catalog team ships an update.
Common follow-ups: What happens if two separate micro frontends both depend on different versions of the same shared library?;How does Module Federation handle sharing common dependencies, like Angular itself, to avoid loading them twice?
Build
Environments & Deployment;Angular CLI & Project Structure
What are the main strategies for composing multiple micro frontends together into one user experience?
Intermediate
Common strategies include a shell application that dynamically loads other applications at runtime, often using Module Federation, using web components like Angular Elements to embed independently built pieces, or server side composition, where a server assembles pieces from different applications before sending the final page to the browser.
// A shell app's routing configuration loading different micro frontends per route
const routes = [
{ path: 'catalog', loadChildren: () => loadRemoteModule('catalog', './Module') },
{ path: 'checkout', loadChildren: () => loadRemoteModule('checkout', './Module') }
];
Real-world example
A shell application routes users to a completely separate checkout micro frontend when they visit the checkout section, and to a separately built catalog micro frontend for browsing products, composing them seamlessly through routing.
Common follow-ups: Which composition strategy generally provides the smoothest experience for end users?;How do you keep a consistent visual style across micro frontends built by different teams?
Routing;Angular Elements (Web Components)
What are some of the main challenges teams face when adopting a micro frontend architecture with Angular?
Advanced
Common challenges include keeping a consistent design and user experience across independently built pieces, managing shared state between separate applications that do not naturally share the same Angular injector, avoiding duplicate loading of large shared dependencies, and coordinating versioning and communication between teams that now work on genuinely separate codebases.
// Sharing state between micro frontends often relies on a shared, framework agnostic event bus
window.dispatchEvent(new CustomEvent('cart-updated', { detail: { itemCount: 3 } }));
// A separate micro frontend listens for the same event
window.addEventListener('cart-updated', (e) => updateCartBadge(e.detail.itemCount));
Real-world example
A company adopting micro frontends builds a small shared event bus using plain browser custom events, letting their independently built cart and header micro frontends stay in sync without directly depending on each other's internal code.
Common follow-ups: What tools exist specifically to help manage shared state across a micro frontend architecture?;How do teams typically handle testing an entire user flow that spans multiple separately deployed micro frontends?
State Management;Performance & Lazy Loading
When is a micro frontend architecture usually not worth the added complexity for a project?
Beginner
For smaller applications or teams, a micro frontend architecture adds significant operational complexity, like managing multiple deployments, shared dependency versions, and cross team coordination, that usually is not justified unless the application and organization have genuinely grown large enough to need independent teams shipping separate pieces on their own schedules.
// A simpler alternative for most projects: Angular's own lazy loaded feature modules
const routes = [
{ path: 'catalog', loadChildren: () => import('./catalog/catalog.routes') }
];
// Still splits code for performance, without the operational overhead of separate deployments
Real-world example
A small startup with a single small team building their first product sticks with Angular's own lazy loaded feature modules instead of adopting a full micro frontend architecture, avoiding unnecessary operational complexity they do not yet need.
Common follow-ups: At what specific signs should a growing team start seriously considering micro frontends?;What is a good simpler middle ground before committing to a full micro frontend architecture?
Performance & Lazy Loading;NgModules & Modular Architecture