Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

マイクロフロントエンド

最終更新 Markdown で表示Agent セットアップ

マイクロフロントエンドを使うと、1 つのアプリケーションを、まとまりのある 1 つのアプリとして描画される、より小さく独立してデプロイできる単位に分割できます。チームごとに異なる技術を使い、各マイクロフロントエンドを開発、テスト、デプロイできます。

マイクロフロントエンドは、次のようなときに使います。

  • リリース調整なしに、多くのチームが独立してデプロイできるようにする
  • モノリスから分散アーキテクチャへ段階的に移行する
  • 複数フレームワークのアプリケーションを作る（例: 1 つのアプリに Astro、Remix、Next.js）

はじめに

マイクロフロントエンドプロジェクトを作成します。

Cloudflare にデプロイ

このテンプレートは、ルーティングロジックをあらかじめ設定したルーター Worker を自動作成します。Cloudflare アカウントにすでにデプロイ済みの Worker へ Service bindings を設定できます。テンプレートのコードは GitHub の cloudflare/templates ↗ にあります。

仕組み

graph LR
    A[ブラウザーからのリクエスト] --> B[ルーター Worker]
    B -->|Service Binding| C[マイクロフロントエンド A]
    B -->|Service Binding| D[マイクロフロントエンド B]
    B -->|Service Binding| E[マイクロフロントエンド C]

ルーター Worker の処理は次のとおりです。

  1. 受信リクエストのパスを解析する
  2. 設定されたルートと照合する
  3. サービスバインディング経由で、該当するマイクロフロントエンドへリクエストを転送する
  4. アセットが正しく読み込まれるよう、HTML、CSS、ヘッダーを書き換える
  5. レスポンスをブラウザーへ返す

各マイクロフロントエンドは次のいずれかです。

  • フルフレームワークのアプリケーション（Next.js、SvelteKit、Astro など）
  • Workers Static Assets を使った静的サイト
  • 異なるフレームワークや技術で構築したもの

ルーティングロジック

ルーター Worker は、どのマイクロフロントエンドが各パスを処理するかを、ROUTES 環境変数 で判断します。ルートは具体性で照合し、より長いパスが優先されます。

ROUTES 設定の例:

{
	"routes": [
		{ "path": "/app-a", "binding": "MICROFRONTEND_A", "preload": true },
		{ "path": "/app-b", "binding": "MICROFRONTEND_B", "preload": true },
		{ "path": "/", "binding": "MICROFRONTEND_HOME" }
	],
	"smoothTransitions": true
}

各ルートに必要な項目は次のとおりです。

  • path: マイクロフロントエンドのマウントパス（ほかのルートと重複しないこと）
  • binding: Wrangler 設定ファイル 内のサービスバインディング名
  • preload（任意）: より速い遷移のため、このマイクロフロントエンドをプリフェッチするかどうか

/app-a/dashboard へのリクエストが来ると、ルーターは次を行います。

  1. /app-a ルートに照合する
  2. リクエストを MICROFRONTEND_A へ転送する
  3. /app-a プレフィックスを取り除き、マイクロフロントエンドには /dashboard が届く

ルーターのパス照合は、次をサポートします。

// Static paths
{ "path": "/dashboard" }

// Dynamic parameters
{ "path": "/users/:id" }

// Wildcard matching (zero or more segments)
{ "path": "/docs/:path*" }

// Required segments (one or more segments)
{ "path": "/api/:path+" }

パスの書き換え

ルーター Worker は HTMLRewriter を使い、HTML 属性へマウントパスのプレフィックスを自動で付けます。アセットが正しい場所から読み込まれるようにします。

/app-a にマウントされたマイクロフロントエンドが次の HTML を返す場合:

<link rel="stylesheet" href="/assets/styles.css" />
<script src="/assets/app.js"></script>
<img src="/static/logo.png" />

ルーターは次のように書き換えます。

<link rel="stylesheet" href="/app-a/assets/styles.css" />
<script src="/app-a/assets/app.js"></script>
<img src="/app-a/static/logo.png" />

リライターは、すべての HTML 要素で次の属性を処理します。

  • href、src、poster、action、srcset
  • data-src、data-href、data-background などの data-* 属性
  • astro-component-url などのフレームワーク固有属性

外部 URL を壊さないよう、ルーターが書き換えるのは、設定されたアセットプレフィックスで始まるパスだけです。

// Default asset prefixes
const DEFAULT_ASSET_PREFIXES = [
	"/assets/",
	"/static/",
	"/build/",
	"/_astro/",
	"/fonts/",
];

ほとんどのフレームワークはデフォルトのプレフィックスで動作します。ビルド成果物のパスが異なるフレームワーク（/_next/ を使う Next.js など）では、ASSET_PREFIXES 環境変数 でカスタムプレフィックスを設定できます。

["/_next/", "/public/"]

アセットの扱い

ルーターは CSS ファイルも書き換え、url() 参照が正しく動くようにします。/app-a にマウントされたマイクロフロントエンドが次の CSS を返す場合:

.hero {
	background: url(/assets/hero.jpg);
}

.icon {
	background: url("/static/icon.svg");
}

ルーターは次のように書き換えます。

.hero {
	background: url(/app-a/assets/hero.jpg);
}

.icon {
	background: url("/app-a/static/icon.svg");
}

ルーターは次も処理します。

  • リダイレクトヘッダー: マウントパスを含めるよう Location ヘッダーを書き換える
  • Cookie のパス: マウントパスにスコープするよう Set-Cookie ヘッダーを更新する

ルートのプリロード

静的なマウントルートに preload: true を設定すると、ルーターはそのルートを自動でプリロードし、遷移を速くします。ルーターは ブラウザーごとの最適化 を使い、各ブラウザーで最も良い性能を出します。

Chromium 系ブラウザー（Chrome、Edge、Opera、Brave）

Chromium 系ブラウザーでは、最新のブラウザーネイティブなプリフェッチ機構である Speculation Rules API を使います。

  • <head> 要素に <script type="speculationrules"> を挿入する
  • ブラウザーが優先度を適切に管理しながら、プリフェッチを自動で行う
  • ユーザー設定（バッテリーセーバー、データセーバー）を尊重する
  • より速いアクセスのため、ドキュメント単位のメモリ内キャッシュを使う
  • Cache-Control ヘッダーでブロックされない
  • JavaScript ベースのフェッチより効率的

挿入される speculation rules の例:

{
	"prefetch": [
		{
			"urls": ["/app1", "/app2", "/dashboard"]
		}
	]
}

スムーズな遷移

View Transitions API ↗ を使い、マイクロフロントエンド間のページ遷移を滑らかにできます。

スムーズな遷移を有効にするには、ROUTES 設定で "smoothTransitions": true を設定します。

{
	"routes": [
		{ "path": "/app-a", "binding": "MICROFRONTEND_A" },
		{ "path": "/app-b", "binding": "MICROFRONTEND_B" }
	],
	"smoothTransitions": true
}

ルーターは HTML レスポンスに CSS を自動挿入します。

@supports (view-transition-name: none) {
	::view-transition-old(root),
	::view-transition-new(root) {
		animation-duration: 0.3s;
		animation-timing-function: ease-in-out;
	}
	main {
		view-transition-name: main-content;
	}
	nav {
		view-transition-name: navigation;
	}
}

この機能は、View Transitions API をサポートするブラウザーでのみ動作します。未対応のブラウザーは、アニメーションなしで通常どおり遷移します。

新しいマイクロフロントエンドを追加する

初期セットアップ後に、アプリケーションへ新しいマイクロフロントエンドを追加する手順です。

  1. 新しいマイクロフロントエンド Worker を作成してデプロイする

    新しいマイクロフロントエンドを、別の Worker としてデプロイします。フレームワークアプリケーション（Next.js、Astro など）でも、Workers Static Assets を使った静的サイトでも構いません。

  2. ルーターの Wrangler 設定ファイルに サービスバインディング を追加する

    {
  "$schema": "./node_modules/wrangler/config-schema.json",
  "services": [
    {
      "binding": "MICROFRONTEND_C",
      "service": "my-new-microfrontend"
    }
  ]
}
    [[services]]
binding = "MICROFRONTEND_C"
service = "my-new-microfrontend"

  3. ROUTES 環境変数を更新する

    ROUTES 設定に新しいルートを追加します。

    {
	"routes": [
		{ "path": "/app-a", "binding": "MICROFRONTEND_A", "preload": true },
		{ "path": "/app-b", "binding": "MICROFRONTEND_B", "preload": true },
		{ "path": "/app-c", "binding": "MICROFRONTEND_C", "preload": true },
		{ "path": "/", "binding": "MICROFRONTEND_HOME" }
	]
}

  4. ルーター Worker を再デプロイする

    npx wrangler deploy

新しいマイクロフロントエンドは、設定したパス（例: /app-c）でアクセスできます。

ローカル開発

開発中は、Wrangler のサービスバインディング対応を使い、マイクロフロントエンド構成をローカルでテストできます。ルーター Worker は wrangler dev でローカル実行し、各マイクロフロントエンドは別のターミナルで実行します。

1 つのマイクロフロントエンドだけ作業する場合は、remote bindings でほかをリモート実行できます。ソースコードへのアクセスや、ローカル開発サーバーの起動は不要です。

ローカル開発中にリモート実行する各マイクロフロントエンドについて、サービスバインディングに remote フラグを設定します。

{
"services": [
	{
	"binding": "<BINDING_NAME>",
	"service": "<WORKER_NAME>",
	"remote": true
	}
]
}
[[services]]
binding = "<BINDING_NAME>"
service = "<WORKER_NAME>"
remote = true

デプロイ

各マイクロフロントエンドは、ルーターやほかのマイクロフロントエンドを再デプロイせず、独立してデプロイできます。これにより、チームは次ができます。

  • 各自のスケジュールで更新をデプロイする
  • ほかに影響を与えず、個別のマイクロフロントエンドをロールバックする
  • 機能を独立してテストし、リリースする

マイクロフロントエンド Worker をデプロイすると、ルーターはサービスバインディング経由で最新バージョンへ自動的にルーティングします。新しいルートの追加や ROUTES 設定の更新がない限り、ルーター側の変更は不要です。

本番へデプロイするには、ルーター Worker に カスタムドメイン を使い、Git リポジトリからの継続的デプロイに Workers Builds を設定できます。

役に立ちましたか？