Week 26: Micro-Frontends & Advanced Architecture

1. What Are Micro-Frontends, and When They're Worth It

A micro-frontend is the same idea as a microservice, applied to the browser: instead of one team owning one large frontend codebase, multiple independently deployable frontend pieces — each owned, built, tested, and shipped by a different team — combine at runtime into what the end user experiences as a single product. One team might own the checkout flow, another the product catalog, another account settings — each deploys on its own schedule, without coordinating a release with the others.

That's genuinely valuable in the right situation, and genuinely harmful complexity in the wrong one. Being direct about which signals point which way matters more than knowing the mechanics — the mechanics (Sections 2–5) are the easy part.

• Signals it's justified — multiple teams, each large enough to own a full vertical slice, shipping on independent schedules that a shared release train would bottleneck; genuinely separate product surfaces (a marketing site vs. a logged-in dashboard vs. an admin panel) with different performance and update-cadence needs; an org where the coordination cost of one shared codebase across teams has become the actual bottleneck, measurably.
• Signals it's premature — a single team, or a single app, reaching for it because the pattern sounds sophisticated or "how big companies do it"; a codebase whose complexity problem is really about internal organization (feature folders, module boundaries) rather than needing separate deployments at all; a team of five people who would spend more time on Module Federation configuration and cross-app coordination than they'd ever save.

2. Module Federation Basics

Module Federation is the mechanism that makes micro-frontends practical at the code level: it lets one already-built, already-deployed JavaScript application (a remote) expose specific modules — a component, a hook, a whole page — that a different application (the host, or "shell") can import and render at runtime, without either app needing to be rebuilt or redeployed when the other changes. This is meaningfully different from an iframe: components rendered via Module Federation share the same DOM, the same React tree context can be threaded through deliberately, and there's no iframe sandboxing overhead or cross-frame messaging required just to pass props.

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import federation from '@originjs/vite-plugin-federation';

export default defineConfig({
  plugins: [
    react(),
    federation({
      name: 'checkout',
      filename: 'remoteEntry.js',
      exposes: {
        './CheckoutSummary': './src/components/CheckoutSummary.tsx',
      },
      shared: ['react', 'react-dom'], // avoid loading React twice across host + remote
    }),
  ],
  build: { target: 'esnext', modulePreload: false, cssCodeSplit: false },
});

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import federation from '@originjs/vite-plugin-federation';

export default defineConfig({
  plugins: [
    react(),
    federation({
      name: 'shell',
      remotes: {
        // points at the deployed remote's manifest -- a URL, not a local import
        checkout: 'https://checkout.example.com/assets/remoteEntry.js',
      },
      shared: ['react', 'react-dom'],
    }),
  ],
  build: { target: 'esnext' },
});

import { lazy, Suspense } from 'react';

// looks like a normal dynamic import, but resolves against the remote's
// deployed remoteEntry.js at runtime -- checkout's own deploys update this
// automatically, with no rebuild of the shell required
const CheckoutSummary = lazy(() => import('checkout/CheckoutSummary'));

function CartPage() {
  return (
    <div>
      <h1>Your Cart</h1>
      <Suspense fallback={<p>Loading checkout...</p>}>
        <CheckoutSummary />
      </Suspense>
    </div>
  );
}

The shared: ['react', 'react-dom'] line matters more than it looks — without it, the host and remote would each ship their own copy of React, and mounting a remote component inside the host's tree would violate React's rule that only one copy of React can own a given component tree, causing subtle hook and context bugs. Module Federation deduplicates shared dependencies at load time when versions are compatible.

3. Monorepo Structuring with Nx or Turborepo

It's easy to conflate "micro-frontends" with "monorepo" because they're often adopted together, but they answer different questions. A monorepo is about where your code lives — one repository, multiple packages, shared tooling and dependency versions. Micro-frontends are about how your app deploys — multiple independently-releasable runtime units. You can have either without the other: a monorepo of packages that all build into one deployed app, or multiple repos (each its own git history) that federate together at runtime.

my-org/
├── apps/
│   ├── shell/            # the host app -- owns routing, top-level layout
│   ├── checkout/          # remote -- owned by the checkout team
│   └── catalog/            # remote -- owned by the catalog team
├── packages/
│   ├── ui/                  # shared design-system components (Section 4)
│   ├── api-client/           # shared typed fetch wrappers
│   └── config/                 # shared eslint/tsconfig presets
├── turbo.json
└── package.json

{
  "$schema": "https://turbo.build/schema.json",
  "tasks": {
    "build": {
      "dependsOn": ["^build"],       // build a package's dependencies first
      "outputs": ["dist/**"]
    },
    "test": {
      "dependsOn": ["^build"],
      "outputs": []
    },
    "lint": {
      "outputs": []
    },
    "dev": {
      "cache": false,
      "persistent": true
    }
  }
}

The payoff of a monorepo here isn't the runtime architecture at all — it's developer experience: turbo run build figures out the dependency graph between packages/ui, packages/api-client, and every app that consumes them, builds only what changed (and its dependents), and caches the rest. A checkout team changing apps/checkout doesn't rebuild apps/catalog unless catalog actually depends on something checkout touched.

4. Shared Design Systems & Component Libraries

When multiple teams ship independently-deployed apps, keeping the product feeling like one product requires a shared source of truth for the basics — buttons, form fields, spacing, color tokens. A packages/ui package inside the monorepo from Section 3 is the standard answer: one place to define a component once, and every app imports it rather than re-implementing its own button.

import { type ButtonHTMLAttributes, type Ref } from 'react';
import styles from './Button.module.css';

type Variant = 'primary' | 'secondary' | 'danger';

interface ButtonProps extends ButtonHTMLAttributes<HTMLButtonElement> {
  variant?: Variant;
  ref?: Ref<HTMLButtonElement>;
}

export function Button({ variant = 'primary', className, ref, ...rest }: ButtonProps) {
  return (
    <button ref={ref} className={`${styles.button} ${styles[variant]} ${className ?? ''}`} {...rest} />
  );
}

{
  "name": "@my-org/ui",
  "version": "3.2.0",
  "main": "./dist/index.js",
  "types": "./dist/index.d.ts",
  "peerDependencies": { "react": "^19.0.0" }
}

import { Button } from '@my-org/ui';

function CheckoutSummary() {
  return (
    <div>
      <p>Total: $84.00</p>
      <Button variant="primary">Place order</Button>
    </div>
  );
}

This creates a real tension worth naming honestly. Sharing @my-org/ui is exactly what keeps checkout and catalog looking like the same product — consistent buttons, consistent spacing, one place to fix an accessibility bug for every app at once. But it's also a coupling point: every app that depends on it now has to deal with its releases, and a breaking change in Button's API means coordinating an upgrade across every consumer — the exact kind of cross-team coordination cost micro-frontends were adopted to avoid in the first place. Semantic versioning and a deliberately small, stable surface area for packages/ui (fewer props, fewer variants, changed rarely) are how teams keep that coupling manageable instead of load-bearing.

5. Cross-App Communication & Independent Deployability

Two independently-deployed apps occasionally need to talk to each other — the shell needs to know when checkout finishes, or catalog needs to tell the shell to update a cart badge count. The instinct to reach for a shared global store (a cross-app Redux instance, say) is exactly the wrong move: it re-creates the tight coupling — one shared piece of state every app must agree on the shape of, version together, and never break — that independent deployability was supposed to eliminate.

Three lighter-weight patterns keep apps decoupled while still letting them communicate:

// inside the checkout remote, after a successful purchase
window.dispatchEvent(
  new CustomEvent('cart:updated', { detail: { itemCount: 0 } })
);

// inside the shell, listening -- doesn't need to know anything about checkout's internals
useEffect(() => {
  function handleCartUpdate(e: Event) {
    const { itemCount } = (e as CustomEvent).detail;
    setCartBadgeCount(itemCount);
  }
  window.addEventListener('cart:updated', handleCartUpdate);
  return () => window.removeEventListener('cart:updated', handleCartUpdate);
}, []);

// packages/event-bus/src/index.ts
type Events = { 'cart:updated': { itemCount: number } };

class EventBus {
  private target = new EventTarget();

  emit<K extends keyof Events>(name: K, detail: Events[K]) {
    this.target.dispatchEvent(new CustomEvent(name, { detail }));
  }

  on<K extends keyof Events>(name: K, handler: (detail: Events[K]) => void) {
    const listener = (e: Event) => handler((e as CustomEvent).detail);
    this.target.addEventListener(name, listener);
    return () => this.target.removeEventListener(name, listener);
  }
}

export const eventBus = new EventBus(); // typed, but still just a thin events wrapper

Option 3 — URL/query-param state — is often the simplest of all for anything that should survive navigation between apps: a ?promoCode=SAVE10 carried across a redirect from catalog to checkout requires no shared code whatsoever, just an agreed-on param name, and works even if the two apps are on entirely separate domains.

What "independently deployable" actually buys a team day to day: the checkout team can ship a fix on a Tuesday afternoon without asking the catalog team to also deploy, without a shared release branch, and without their change being blocked by an unrelated team's in-progress work. That's the entire point — every pattern in this section is chosen specifically because it doesn't require the two teams' deploys to be coordinated.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.