Introduction to Remote Components

Throughout this course, you've built vertical microfrontends: splitting by route where each page belongs to one application. Remote components are the horizontal approach: embedding components from different applications on the same page.

Outcome

Understand the difference between vertical and horizontal microfrontends and know when to consider remote components.

Vertical vs Horizontal Recap

Vertical (what you've built):

Page at /docs/api
└── Entirely served by docs app
    ├── Header (shared package)
    ├── Content
    └── Footer (shared package)

Horizontal (remote components):

Page at /
└── Served by marketing app
    ├── Header (REMOTE from header-app)
    ├── Hero (local component)
    ├── Features (local component)
    └── Footer (REMOTE from footer-app)

With horizontal microfrontends, components from different applications render on the same page at runtime.

When to Consider Horizontal

Remote components solve specific problems:

How Remote Components Work

At a high level:

// Host application
import { RemoteComponent } from "@vercel/microfrontends/react";
 
export default function Page() {
  return (
    <div>
      <RemoteComponent
        src="header-app"
        fallback={<HeaderSkeleton />}
      />
      <main>Page content</main>
      <RemoteComponent src="footer-app" />
    </div>
  );
}

The remote component:

1. Fetches from the remote application (header-app)
2. Renders the component as if it were local
3. No iframes - It's embedded directly in the DOM
4. SSR/SSG support - Server-renders like native components

State Sharing

The most common question: "How do I share state between host and remote?"

Module sharing allows React context to work across applications:

// Configuration in next.config.ts
export default withMicroFrontends(nextConfig, {
  shared: {
    react: { singleton: true },
    "@acme/context": { singleton: true },
  },
});

When both host and remote use @acme/context, they share the same context instance. A theme toggle in the host updates the remote header's dark mode.

Current Status

Remote components are in alpha. Schwab and The Weather Company are beta testing. Production-ready for early adopters working directly with Vercel.

Vertical-First Philosophy

For most teams, the recommendation is:

1. Start with vertical microfrontends (this course)
2. Use shared packages for common components
3. Consider horizontal only when shared packages aren't enough

Horizontal adds complexity:

• Module sharing configuration
• Cache invalidation when remotes update
• More moving parts to debug

Vertical is simpler and solves most use cases.

When Vertical Isn't Enough

Consider remote components when:

• Same component, many hosts - A header used by 10+ separate applications (not in a monorepo)
• Independent deployment of components - Marketing wants to update the header without docs redeploying
• Different teams, same page - Team A owns navigation, Team B owns search, Team C owns content

Example: Multi-Site Header

Imagine you have:

• marketing.example.com
• docs.example.com
• app.example.com

All need the same header. With shared packages in a monorepo, you'd need to redeploy all three when the header changes.

With remote components:

1. header-app deploys
2. All hosts pick up the new header (via ISR revalidation)
3. No coordination needed

SSG/ISR with Remotes

Remote components support static generation:

Build time:
Host fetches remote component → Renders → Saves static HTML

Runtime (ISR):
Remote updates → Host revalidates → New HTML includes updated remote

Currently, invalidation is manual. You trigger revalidation on the host when a remote updates.

The Future

The Vercel team is working on:

• Automatic invalidation - Host auto-revalidates when remote deploys
• Better debugging - See remote component boundaries in DevTools
• Simplified configuration - Less boilerplate for module sharing

Done-When

• You understand vertical vs horizontal microfrontends
• You know when to consider remote components
• You understand module sharing for state
• You know remote components are currently in alpha

Decision Guide

What's Next

Wrap up with the decision framework and resources for going deeper.

In the final lesson, you'll review the key decisions and get resources for continuing your microfrontends journey.