Course
Micro Frontend
77 lessons across 9 modules
Advanced, assuming JavaScript, React, TypeScript and some frontend architecture. Fundamentals and the case against, shell and remote architecture, Module Federation, communication, routing and auth, independent deployment, and production - ending in an enterprise shell with three remotes. The road is laid out in full; lessons are being written one at a time.
Micro Frontend Fundamentals
What it is, and the honest case against it
The microservices patterns course →What is Micro Frontend?
1Independently built and deployed pieces of one user-facing app.
One page assembled from three separately released builds
Why Micro Frontend?
2The organisational problem it solves, which is not a technical one.
Four teams blocked behind one release train
Monolith vs Micro Frontend
3What a frontend monolith does well, and where it stops.
The same app both ways, compared on release cadence
Micro Frontend vs Microservices
4The analogy, and the three places it breaks down.
Why the browser makes this harder than the server side
Benefits and Challenges
5Autonomy and isolation, paid for in duplication and complexity.
The costs listed as plainly as the benefits
When to Use Micro Frontend
6The conditions that make it worth the price.
Team count, release friction, and domain boundaries
When NOT to Use Micro Frontend
7The far more common answer, and how to recognise it.
One team of six adopting it, and regretting it
Micro Frontend Architecture
Shell, remotes, and who owns what
Micro Frontend Architecture
8The shapes available, and what each one commits you to.
Build-time, server-side, and runtime integration compared
Application Shell
9The container that owns layout, routing, and the session.
A shell that stays up when a remote does not
Host and Remote Applications
10Who loads whom, and the contract between them.
Drawing the dependency arrows before any code
Domain-based Decomposition
11Splitting by business domain rather than by page or by layer.
A split along technical lines that recreates the coupling
Team Ownership
12One team per remote, end to end - the point of the whole exercise.
Conway law read as a design constraint
Independent Development
13Running one remote alone, without the rest of the system.
A standalone mode that makes local work bearable
Independent Deployment
14Shipping one remote without rebuilding the host.
A deploy that touches one bundle and no others
Runtime Integration
15Composing in the browser, and what that costs on first paint.
Measuring the extra round trip a remote adds
Module Federation
The mechanism most of this is built on
What is Module Federation?
16Loading code from another build at runtime, and why that is new.
An import that resolves over the network
Host Application
17Configuring a consumer, and what it must know in advance.
A host that discovers remotes rather than hard-coding them
Remote Application
18Configuring a producer, and the manifest it publishes.
Reading remoteEntry.js and seeing the contract
Exposes
19Choosing the public surface of a remote, and keeping it small.
Exposing one mount point rather than twelve components
Remotes
20Declaring what a host consumes, and resolving URLs per environment.
The same host pointing at staging or production remotes
Shared Dependencies
21Sharing a library instead of shipping it three times.
Two copies of React, and the hooks error that follows
Version Management
22Singletons, required versions, and strict mode.
A remote built against a React the host does not have
Runtime Loading
23Lazy loading a remote, and what to render while it arrives.
A remote that fails to load, handled rather than blank
React Micro Frontend
Building one, host and remotes together
The React course →Creating a Host Application
24The shell project, its config, and its responsibilities.
A host that renders a layout and nothing else
Creating Remote Applications
25A remote that runs standalone and mounts inside a host.
One entry point serving both modes
Sharing React
26One React instance across every build, and why it is mandatory.
Invalid hook call, traced to a duplicate React
Sharing Components
27A design system across remotes, and versioning it.
A button change that lands everywhere without a rebuild
Sharing Utilities
28The helpers worth sharing, and the coupling that follows.
A shared util that becomes a release bottleneck
Routing
29A first pass at host and remote routes coexisting.
A remote that owns everything under one path
Authentication
30A first pass at one session shared by every remote.
A remote that trusts the host for identity
Building a React Micro Frontend
31A host and two remotes, running together end to end.
The smallest complete system that actually works
Communication Between Micro Frontends
Talking across a boundary you deliberately built
The Redux course →Why Communication is Difficult
32Every channel you add trades autonomy back for convenience.
Two remotes that can no longer deploy independently
Props
33The host passing data down, and why this is the default answer.
A mount function taking the user as an argument
Custom Events
34Publishing and subscribing without a shared import.
A cart update two remotes both react to
Browser Events
35The native channels already available, and their limits.
storage events synchronising two tabs
Shared State
36A shared store, and the coupling it quietly introduces.
A state shape change that breaks three teams
Redux Across Micro Frontends
37Dynamic reducer injection, and whether to do this at all.
A remote registering its slice on mount
URL-based Communication
38The URL as shared state that every remote already reads.
A filter in the query string, honoured by two remotes
Communication Best Practices
39Thin contracts, versioned events, and the direction of coupling.
A published event contract treated like an API
Routing and Authentication
One URL bar and one session, across many apps
Host Routing
40The shell owning the top-level map of the app.
A route table that names remotes, not pages
Remote Routing
41A remote owning everything beneath its prefix.
Two routers cooperating over one history
Nested Routes
42Deep links into a remote, resolved correctly on a cold load.
Pasting a deep URL and landing in the right place
Navigation
43Moving between remotes without a full page reload.
A link that crosses a boundary and keeps the shell alive
Authentication
44One login, one token, and where it actually lives.
The host holding the session for everyone
Authorization
45Permissions distributed to remotes that must not re-derive them.
A permission set handed down at mount
Shared Authentication
46Refresh, expiry, and logout coordinated across remotes.
One expired token logging every remote out
Protected Micro Frontends
47Not loading a remote at all unless the user may see it.
An admin remote that is never fetched by a viewer
Deployment and CI/CD
Independent releases, which is the whole point
Independent Builds
48One pipeline per remote, with no shared build step.
A build that does not wait for anyone else
Independent Deployment
49Shipping a remote without touching the host.
A production change with no host release
Versioning
50Versioning the contract, not just the bundle.
A breaking expose change, and how it should have been staged
Remote Deployment
51Where remoteEntry lives, and cache headers that let you roll forward.
A stale manifest serving yesterday bundle
CI/CD Pipelines
52Lint, typecheck, test, build, deploy - per remote.
A pipeline that blocks a broken remote from shipping
Environment Configuration
53Remote URLs per environment, resolved at runtime not build time.
One build promoted through three environments
Rollbacks
54Reverting one remote quickly, without a coordinated release.
Pointing the manifest back at the previous version
Handling Incompatible Versions
55Detecting a mismatch before users do, and failing safely.
A contract check in CI across host and remotes
Production Considerations
Running a distributed frontend for real users
Performance
56The cost of runtime composition, measured rather than assumed.
First paint with one remote against four
Shared Dependencies
57Deduplication as a performance decision, not just a correctness one.
Three copies of a date library in one page
Error Isolation
58One remote failing without taking the shell with it.
An error boundary per remote, and what it renders
Security
59Loading third-party code at runtime, and the trust that implies.
A CSP that still allows federated loading
Observability
60Knowing which remote a problem came from.
A trace that names the remote and its version
Monitoring
61Per-remote health, and alerting the team that owns it.
A dashboard split the same way the org is
Logging
62Correlating logs across independently deployed pieces.
One request id carried through three remotes
Caching
63Long-lived chunks against a manifest that must stay fresh.
Cache rules that let a deploy actually take effect
Failure Handling
64Timeouts, retries, and a degraded page worth showing.
A dashboard missing one panel rather than all of them
Production Best Practices
65The decisions worth making before launch, not after.
A pre-launch review of a federated app
Real-World Project
An enterprise shell with three remotes
Architecture Design
66Boundaries, ownership, and contracts agreed before any code.
The shell and three remotes drawn on one page
Create the Host
67The shell - layout, routing, session, and error boundaries.
A host that renders with no remotes available
Create the Dashboard Remote
68The first remote, standalone and mounted.
Running it alone, then inside the shell
Create the Users Remote
69A second team following the same contract.
A remote built without reading the host source
Create the Courses Remote
70A third remote, and the patterns that have now settled.
The third one taking an afternoon rather than a week
Shared Components
71A design system consumed by all three, versioned deliberately.
One button change rolled out safely
Shared Authentication
72One session across the shell and every remote.
Logging out in one place and everywhere following
Routing
73Deep links, navigation between remotes, and a cold load.
Pasting a URL into a fresh tab and landing correctly
Communication
74The event contract between remotes, written down and versioned.
A notification one remote raises and two consume
Independent Deployment
75Releasing one remote while the others stay untouched.
A deploy nobody else had to be told about
CI/CD
76Four pipelines, contract checks, and per-remote rollback.
A bad remote blocked before it reaches the shell
Production Deployment
77Going live, watching it, and reviewing against the design.
The finished system, and what you would change next time