Problem Statement
As a frontend grows, one big SPA owned by one team becomes a bottleneck: every change ships together, teams step on each other, and you can't deploy a single feature independently. Microfrontends solve this — but the architecture (a host shell loading remotely-built modules at runtime, sharing dependencies safely) is unfamiliar to most engineers. A concrete, runnable example is the best way to teach it.
Proposed Solution
A simple fintech app that demonstrates Webpack Module Federation: a host shell application composes two independently-developed, independently-deployable microfrontends — Loans and Transfer — at runtime. Each runs on its own port in dev (host :3000, loans :3001, transfer :3002), is built separately, and is stitched into the shell. Built originally for a DevFest (Ogbomoso) talk, it's a teaching artifact.
Full Solution Details
- Host (
apps/host, :3000) — the shell that loads and renders the remote microfrontends. - Loans MFE (
apps/loans, :3001) — an independently-built loans feature exposed as a federated remote. - Transfer MFE (
apps/transfer, :3002) — an independently-built transfer feature, federated remote. - Independent install/build — each app has its own dependencies and build, then composes via Module Federation.
Technical Documentation
React + TypeScript + Tailwind, with Webpack Module Federation as the integration mechanism. Each microfrontend is a standalone Webpack build that exposes components; the host consumes them as remotes loaded at runtime (not bundled at build time), with shared dependencies (React, etc.) deduplicated so the browser loads one copy. This is the canonical microfrontend pattern: independent codebases and deploys, runtime composition, and a shell that orchestrates routing/layout — exactly the architecture his Connectic library is designed to support for communication between such MFEs.
Tech Stack
React, TypeScript, Tailwind CSS, Webpack Module Federation; multi-app dev setup (host + 2 remotes).
System Design
Host shell (:3000) ── Webpack Module Federation ──┐ loads remotes at runtime
routing + layout │ (shared deps deduped)
├── remote: Loans MFE (:3001, own build/deploy)
└── remote: Transfer MFE (:3002, own build/deploy)
Each MFE: independent codebase · independent deploy · exposes components
Smart Architectural Decisions
- Runtime composition via Module Federation. Loading remotes at runtime (rather than npm-linking build-time packages) is what enables truly independent deployment — the entire point of microfrontends, demonstrated correctly.
- Clear team-boundary modeling. Splitting Loans and Transfer into separate apps mirrors how real banks split teams/domains — the example teaches the organizational benefit, not just the tech.
- Shared-dependency strategy. Module Federation's dependency sharing (one React copy across MFEs) is the subtle part that makes the approach performant; the example exercises it.
- Built to teach. Created for a conference talk, it's deliberately small and legible — optimized for understanding the pattern.
Impacts
A clear, runnable reference for microfrontend architecture with Module Federation, used to teach other developers — and a concrete companion to his Connectic library (which solves cross-MFE communication for exactly this kind of setup).
Demonstrated Skills
Microfrontend architecture (Webpack Module Federation, runtime remote loading, shared-dependency management); multi-app build orchestration; React + TypeScript + Tailwind; technical teaching/communication (built for a conference talk); understanding of how frontend architecture maps to team/domain boundaries.