Week 24: Micro-Frontends & Advanced Architecture

1. Monorepo Strategies (Nx) for Multi-App Workspaces

You built a basic multi-app workspace by hand back in Week 2. Nx extends that same idea with tooling built specifically for it — dependency-graph-aware builds (only rebuild what actually changed), consistent generators across apps and libraries, and enforceable boundaries between them.

npx create-nx-workspace@latest my-org --preset=angular-monorepo

cd my-org
nx generate @nx/angular:application admin
nx generate @nx/angular:application storefront
nx generate @nx/angular:library ui-kit

{
  "targetDefaults": {
    "build": {
      "dependsOn": ["^build"] // only rebuilds a library's dependents when the library itself changes
    }
  }
}

Nx can also enforce module boundaries — for instance, preventing a feature-specific library from importing directly from another unrelated feature, forcing genuinely shared code through an explicit shared library instead. That constraint is what keeps a large monorepo from decaying into every app quietly depending on every other app's internals.

2. Module Federation & Micro-Frontend Patterns

A monorepo still ships one deployable build per app. Module federation goes further — separate applications, built and deployed independently, that load parts of each other at runtime, in the browser.

// The "host" shell app doesn't bundle the checkout feature at build time --
// it fetches it from another team's independently-deployed application, at runtime:

const CheckoutModule = await loadRemoteModule({
  remoteEntry: 'https://checkout.yourapp.com/remoteEntry.js',
  exposedModule: './Checkout',
});

The practical payoff: the checkout team can deploy independently of the shell team, without coordinating a shared release — each micro-frontend has its own build, its own deploy pipeline, and potentially its own release cadence. The cost: real runtime complexity — version mismatches between shared dependencies, and debugging across multiple independently-deployed applications instead of one.

3. Shared Design-System Libraries Across Apps

Whether or not you go as far as module federation, a shared UI library keeps multiple apps visually and behaviorally consistent — the Button from Week 7, published once, used everywhere.

export * from './lib/button/button';
export * from './lib/modal/modal';
export * from './lib/rating-stars/rating-stars';

A public-api.ts (or index.ts) that explicitly re-exports only what's meant to be consumed externally is worth being deliberate about — it's the library's actual contract with every app that depends on it, distinct from internal implementation files nothing outside the library should import directly.

4. Versioning & Publishing Internal Libraries

Inside an Nx monorepo, every app always uses the library's latest code — there's no version number to manage day to day. Once a library needs to be consumed outside the monorepo (a separate repository, a different team entirely), semantic versioning becomes necessary again.

// MAJOR.MINOR.PATCH
// 2.4.1 -> 2.4.2  Patch: bug fix, no API change -- safe to upgrade blindly
// 2.4.1 -> 2.5.0  Minor: new functionality, backward-compatible -- safe to upgrade
// 2.4.1 -> 3.0.0  Major: breaking change -- requires the consumer to read a changelog

A private npm registry (or a tool like Nx's own release tooling) publishes internal libraries the same way public npm packages are published — the discipline of semantic versioning is exactly what lets consuming teams upgrade confidently, or hold back deliberately when a major version lands.

5. Choosing Monolith vs. Micro-Frontend for a Given Team Size

A pattern worth internalizing, since it recurs across this entire course:

• Single team, single app — a monolith (everything from Weeks 1-23) is almost always correct. No coordination problem exists yet to solve.
• Multiple teams, one app, frequent deploy conflicts — an Nx monorepo with clear module boundaries often solves this without full runtime micro-frontends at all.
• Multiple teams needing genuinely independent deploy cadences, at real organizational scale — this is where module federation earns its complexity.

Micro-frontends solve an organizational problem (teams stepping on each other, coupled release cycles) far more than a technical one — a small team adopting module federation "for scalability" before there's a second team to actually decouple from is taking on real runtime complexity for a problem that doesn't exist yet.

6. A Reference Architecture

Putting Sections 1-5 together, a realistic setup for a mid-sized organization with a few product teams:

nx-workspace/
├── apps/
│   ├── shell/              # thin host app: nav, auth, layout
│   ├── dashboard/          # one team's feature area
│   └── billing/            # another team's feature area
├── libs/
│   ├── ui-kit/             # shared design-system components (Section 3)
│   ├── auth/                # shared Week 23 auth logic, one implementation
│   └── shared-types/        # shared TypeScript interfaces across apps

Notice this doesn't necessarily require module federation at all — a well-structured Nx monorepo with shared libraries already solves most of the coordination problem. Reach for runtime module federation specifically when teams need independent deployment, not just independent development within a shared repo.

7. Hands-on Exercise

8. Knowledge Check

Four quick questions. Expand each to check your answer.