はじめに
Micro Frontend は、マイクロサービスの概念を フロントエンド に拡張します。つまり、Web アプリケーションを小さな部分に分割し、各部分はチームによって 独立して所有、開発、デプロイされます。この記事では、Micro Frontend が必要な理由と、いつ使用する必要があるか (または使用すべきでない場合) について説明します。
1. マイクロフロントエンドとは何ですか?
1.1 定義
「独立して提供可能なフロントエンド アプリケーションがより大きな全体として構成されるアーキテクチャ スタイル。」 — カム・ジャクソン、マーティン・ファウラーのブログ
Monolith Frontend: Micro Frontend:
┌─────────────────────────┐ ┌─────────────────────────┐
│ Single SPA │ │ Shell Application │
│ ┌─────────────────────┐ │ │ ┌──────┐ ┌──────┐ ┌──┐ │
│ │ Header │ │ │ │Shared│ │Shared│ │ │ │
│ ├──────┬──────┬───────┤ │ │ │Header│ │Footer│ │ │ │
│ │Produ-│ Cart │ Order │ │ │ └──────┘ └──────┘ │ │ │
│ │cts │ │ │ │ │ ┌──────┐ ┌──────┐ │ │ │
│ │ │ │ │ │ ──► │ │Produc│ │ Cart │ │Or│ │
│ │ │ │ │ │ │ │t MFE │ │ MFE │ │de│ │
│ │ │ │ │ │ │ │Team A│ │Team B│ │rC│ │
│ ├──────┴──────┴───────┤ │ │ └──────┘ └──────┘ └──┘ │
│ │ Footer │ │ │ Deploy Deploy De │
│ └─────────────────────┘ │ │ riêng riêng ploy │
└─────────────────────────┘ └─────────────────────────┘
1 team, 1 repo, 1 deploy N teams, N repos, N deploys
1.2 マイクロ フロントエンドとコンポーネント ライブラリ
| コンポーネント ライブラリ | マイクロ フロントエンド | |
|---|---|---|
| デプロイ | 同じアプリホスト | 独立 |
| チームの所有権 | 共有 | 専任チーム |
| 技術スタック | 類似 | 異なる場合があります |
| ランタイムロード | ビルド時間 | ランタイム |
| データ/状態 | メモリ内で共有 | 孤立した |
2. なぜマイクロフロントエンドが必要なのでしょうか?
2.1 実際的な問題
5 つのチームが 1 つのモノリス SPA に取り組んでいます。
- 継続的な PR 競合 (500 以上のコンポーネント、共有状態)
- 長いマージ キュー → 週に 1 回デプロイ
- チームは React 18 をアップグレードしたいが、アプリ全体を移行する必要がある
- 商品ページのバグ→アプリ全体をロールバック（カート、注文にも影響あり）
→ Micro Frontend は 組織のスケーリング 問題を解決します。
2.2 主な利点
| メリット | 説明 |
|---|---|
| 独立した展開 | カートに影響を与えずに商品ページを発送 |
| チームの自律性 | 各チームはエンドツーエンド (UI → BFF → サービス) を所有します。 |
| 技術的な柔軟性 | チーム A は React を使用し、チーム B は Vue を使用します (必要な場合) |
| 増分アップグレード | 各 MFE をアップグレード、ビッグバンは不要 |
| 障害の分離 | MFE A のバグは MFE B をクラッシュさせません。 |
| 開発の迅速化 | コードベースが小さい = ビルド、テスト、デプロイが高速化 |
3. トレードオフと課題
3.1 Micro Frontendが適さない場合
- 小規模チーム (< 5 開発者): メリットに比べてオーバーヘッドが大きすぎます。
- シンプルなアプリ: ランディング ページ、ブログ、シンプルなダッシュボード
- 緊密な UX 結合: アプリケーションにはパーツ間のシームレスな UX が必要です
- パフォーマンスクリティカル: 実行時のオーバーヘッドを追加します (読み込み、ブートストラップ)
3.2 複雑さのコスト
Micro Frontend thêm complexity:
├── Infrastructure: CI/CD cho nhiều apps
├── Shared dependencies: versioning hell
├── UX Consistency: design system bắt buộc
├── Communication: cross-MFE events
├── Performance: bundle size, load time
├── Testing: integration testing across MFEs
└── Developer Experience: local dev setup phức tạp
4. 意思決定の枠組み
Bạn nên dùng Micro Frontend khi:
✅ Team size: 15+ frontend developers
✅ Multiple teams working on same app
✅ Deploy frequency: team muốn deploy độc lập
✅ App complexity: 10+ distinct features/pages
✅ Tech migration: cần incremental migration
❌ Skip Micro Frontend khi:
❌ Team < 5 developers
❌ Single team, shared ownership
❌ App chưa đủ phức tạp
❌ Performance là yếu tố quyết định
❌ Team chưa có experience với Microservices
概要
Micro Frontend は特効薬ではありません。組織のスケーリング の問題を解決します。そのような問題がない場合は、不必要な複雑さを生じさせないでください。