マイクロフロントエンド 第2版

―柔軟性に優れ、信頼性、自律性の高いシステムを構築する

[cover photo]
TOPICS
System/Network
発行年月日
PRINT LENGTH
408
ISBN
978-4-8144-0184-0
原書
Building Micro-Frontends, 2nd Edition
FORMAT
Print
Print
5,060円

DAZNでアーキテクトを務めた著者が、マイクロフロントエンドの概念、利点と注意点、導入判断のコツを実践的に解説します。デプロイ容易性、モジュール性、テスト容易性、性能、開発者体験の観点から設計を評価する視点を示し、自律的で生産性の高いチームづくりのヒントを提供。ケーススタディも盛り込み、導入の具体的なイメージができるように構成されています。サンプルコードはGitHubで利用可能。

目次

第1版の序 
まえがき 

1章 マイクロフロントエンドの原則 
    1.1 モノリスから分散システムへ 
    1.2 マイクロサービスへの移行 
    1.3 マイクロフロントエンドの導入 
    1.4 マイクロサービスの原則 
        1.4.1 ビジネスドメインのモデル化 
        1.4.2 自動化の文化 
        1.4.3 実装の詳細を隠す 
        1.4.4 分権化 
        1.4.5 独立デプロイ 
        1.4.6 障害の分離 
        1.4.7 高い可観測性 
    1.5 マイクロフロントエンドに原則を適用する 
        1.5.1 ビジネスドメインのモデル化 
        1.5.2 自動化の文化 
        1.5.3 実装の詳細を隠す 
        1.5.4 分権化 
        1.5.5 独立デプロイ 
        1.5.6 障害の分離 
        1.5.7 高い可観測性 
    1.6 マイクロフロントエンド特有の課題 
    1.7 マイクロフロントエンドは銀の弾丸ではない 
    1.8 まとめ 

2章 マイクロフロントエンドのアーキテクチャと課題 
    2.1 マイクロフロントエンド意思決定フレームワーク 
    2.2 マイクロフロントエンドの定義 
    2.3 マイクロフロントエンドにおけるDDD 
    2.4 境界づけられたコンテキストを定義する 
    2.5 マイクロフロントエンドの境界をテストする 
    2.6 マイクロフロントエンドのコンポジション 
        2.6.1 クライアントサイドコンポジション 
        2.6.2 エッジサイドコンポジション 
        2.6.3 サーバーサイドコンポジション 
    2.7 マイクロフロントエンドのルーティング 
    2.8 マイクロフロントエンド間の通信 
    2.9 導入例 
        2.9.1 Zalando 
        2.9.2 F1 
        2.9.3 Dunelm 
        2.9.4 Netflix 
        2.9.5 PayPal 
        2.9.6 BMW 
        2.9.7 OpenTable 
        2.9.8 DAZN 
    2.10 まとめ 

3章 マイクロフロントエンドの検出 
    3.1 マイクロフロントエンド意思決定フレームワークの適用 
        3.1.1 垂直分割 
        3.1.2 水平分割 
    3.2 アーキテクチャ分析 
    3.3 アーキテクチャとトレードオフ 
    3.4 垂直分割アーキテクチャ 
        3.4.1 アプリケーションシェル 
        3.4.2 課題 
        3.4.3 アーキテクチャの進化 
        3.4.4 デザインシステムの実装 
        3.4.5 開発者体験 
        3.4.6 パフォーマンスとマイクロフロントエンド 
        3.4.7 利用可能なフレームワーク 
        3.4.8 アーキテクチャ特性 
    3.5 水平分割アーキテクチャ 
        3.5.1 クライアントサイド 
        3.5.2 課題 
        3.5.3 マイクロフロントエンドのリファクタリング 
        3.5.4 検索エンジン最適化 
        3.5.5 開発者体験 
        3.5.6  チーム間の意思疎通と最終成果物を管理するためのベストプラクティス 
        3.5.7 ユースケース 
        3.5.8 利用可能なフレームワーク 
        3.5.9 開発者体験 
        3.5.10 ユースケース 
        3.5.11 アーキテクチャ特性 
    3.6 iframe 
        3.6.1 ベストプラクティスと欠点 
        3.6.2 開発者体験 
        3.6.3 ユースケース 
        3.6.4 アーキテクチャ特性 
    3.7 Webコンポーネント 
        3.7.1 Webコンポーネントの技術 
        3.7.2 依存関係の管理 
        3.7.3 ユースケース 
        3.7.4 アーキテクチャ特性 
    3.8 Web Fragments 
    3.9 サーバーサイド 
        3.9.1 スケーラビリティと応答時間 
        3.9.2 インフラストラクチャの所有権 
        3.9.3 マイクロフロントエンドのコンポジション 
        3.9.4 マイクロフロントエンド通信 
        3.9.5 利用可能なフレームワーク 
        3.9.6 ユースケース 
        3.9.7 アーキテクチャ特性 
    3.10 モダンなサーバーサイドレンダリングフレームワーク 
        3.10.1 ユースケース 
        3.10.2 アーキテクチャ特性 
    3.11 エッジサイド 
    3.12 まとめ 

4章 クライアントサイドレンダリングのマイクロフロントエンド 
    4.1 プロジェクト 
    4.2 モジュールフェデレーション 
    4.3 実装 
        4.3.1 プロジェクト構成 
        4.3.2 アプリケーションシェル 
        4.3.3 ホームマイクロフロントエンド 
        4.3.4 カタログマイクロフロントエンド 
        4.3.5 アカウント管理マイクロフロントエンド 
    4.4 プロジェクトの進化 
        4.4.1 レガシーアプリケーションを埋め込む 
        4.4.2 チェックアウト体験の開発 
        4.4.3 クライアントサイドレンダリングのマイクロフロントエンドプロジェクトをホストする 
        4.4.4 キャッシュ 
    4.5 まとめ 

5章 サーバーサイドレンダリングのマイクロフロントエンド 
    5.1 サーバーサイドレンダリングを使用するタイミング 
    5.2 スケーラビリティの課題 
    5.3 マイクロフロントエンドを分割する 
    5.4 コンポジションのアプローチ 
    5.5 主な課題 
    5.6 HTMLフラグメント 
    5.7 URLで分割する 
    5.8 マイクロフロントエンドで動くF1サイト 
    5.9 Next.jsマルチゾーン 
    5.10  Webアプリケーションのエントリーポイントとなるホームゾーン 
    5.11 共有コンポーネントの扱い方 
    5.12 データを管理する 
        5.12.1 Vercelが描く未来 
    5.13 API戦略 
    5.14  キャッシュを恐れずにスマートな戦略でSSRをスケーリングする 
    5.15 開発者が知っておくべきキャッシュの種類 
        5.15.1 CDN 
        5.15.2 インメモリデータベースキャッシュ 
        5.15.3 ウォームキャッシュ 
    5.16 BBCのアーキテクチャにおけるキャッシュ例 
    5.17  サーバーサイドレンダリングを選ぶ最大の理由 
    5.18 まとめ 

6章 マイクロフロントエンドの自動化 
    6.1 自動化の原則 
        6.1.1 フィードバックループを高速に保つ 
        6.1.2 こまめに改善を重ねる 
        6.1.3 チームに裁量を持たせる 
        6.1.4 ガードレールを定義する 
        6.1.5 テスト戦略を定義する 
    6.2 開発者体験 
        6.2.1 水平分割と垂直分割 
        6.2.2 摩擦のないマイクロフロントエンド計画 
        6.2.3 環境戦略 
    6.3 バージョン管理 
        6.3.1 モノレポ 
        6.3.2 ポリレポ 
        6.3.3 バージョン管理システムの将来像 
    6.4 継続的インテグレーション戦略 
    6.5 マイクロフロントエンドのテスト 
        6.5.1 エンドツーエンドテスト 
        6.5.2 垂直分割エンドツーエンドテストの課題 
        6.5.3 水平分割エンドツーエンドテストの課題 
        6.5.4 テストに関する技術的な推奨事項 
    6.6 適応度関数 
    6.7 マイクロフロントエンド特有の作業 
    6.8 可観測性 
    6.9 まとめ 

7章 マイクロフロントエンドの検出とデプロイ 
    7.1 ブルーグリーンデプロイとカナリアリリース 
    7.2 問題領域 
    7.3 フロントエンドディスカバリースキーマ 
    7.4 フロントエンドディスカバリーパターンの利点 
    7.5 実装 
    7.6 モジュールフェデレーションによる統合例 
    7.7 ディスカバリーパターンを他のソリューションと統合する 
    7.8 機能フラグ 
    7.9 市場で利用できるソリューション 
    7.10 まとめ 

8章 マイクロフロントエンドのための自動化パイプライン 
    8.1 環境を整える 
    8.2 バージョン管理 
    8.3 パイプライン初期化 
    8.4 コード品質レビュー 
    8.5 ビルド 
    8.6 ビルド後レビュー 
    8.7 デプロイ 
    8.8 自動化戦略のまとめ 
    8.9 まとめ 

9章 マイクロフロントエンド向けのバックエンドパターン 
    9.1 API統合とマイクロフロントエンド 
    9.2 サービスディクショナリを扱う 
        9.2.1 垂直分割アーキテクチャでサービスディクショナリを実装 
        9.2.2 水平分割アーキテクチャでサービスディクショナリを実装 
    9.3 APIゲートウェイを扱う 
        9.3.1 ビジネスドメインごとに1つのAPIエントリーポイント 
        9.3.2 APIゲートウェイとサービスディクショナリによるクライアントサイドコンポジション 
        9.3.3 APIゲートウェイによるサーバーサイドコンポジション 
    9.4 BFFパターンを扱う 
        9.4.1  BFFとサービスディクショナリによるクライアントサイドコンポジション 
        9.4.2  BFFとサービスディクショナリを使ったサーバーサイドコンポジション 
    9.5 マイクロフロントエンドでGraphQLを使う 
        9.5.1 スキーマフェデレーション 
        9.5.2 マイクロフロントエンドとクライアントサイドコンポジションでGraphQLを使う 
        9.5.3 マイクロフロントエンドとサーバーサイドコンポジションでGraphQLを使う 
    9.6 ベストプラクティス 
        9.6.1 同じAPIを利用する複数のマイクロフロントエンド 
        9.6.2 APIを先に、実装はその後に 
        9.6.3 APIの一貫性 
        9.6.4 WebSocketとマイクロフロントエンド 
        9.6.5 適切なサブドメインに最適なアプローチ 
    9.7 まとめ 

10章 マイクロフロントエンド実装でよくあるアンチパターン 
    10.1 マイクロフロントエンドかコンポーネントか? 
    10.2 マイクロフロントエンド間で状態を共有する 
    10.3 マイクロフロントエンドの無秩序 
    10.4 腐敗防止層による解決 
    10.5 一方向の共有 
    10.6 早すぎる抽象化 
    10.7 まとめ 

11章 マイクロフロントエンドへの移行 
    11.1 なぜ反復的に進めるのか? 
    11.2 マイクロフロントエンドでどのような問題を解決したいのか? 
        11.2.1 ベストプラクティスとパターン 
        11.2.2 トレードオフと落とし穴 
        11.2.3 チェックリスト 
        11.2.4 簡単な例 
        11.2.5 実体験 
    11.3 移行に対する経営陣の賛同を得るにはどうすればよいか? 
        11.3.1 ベストプラクティスとパターン 
        11.3.2 トレードオフと落とし穴 
        11.3.3 チェックリスト 
        11.3.4 簡単な例 
        11.3.5 実体験 
    11.4 移行をどのように計画すべきか? 
        11.4.1 ベストプラクティスとパターン 
        11.4.2 トレードオフと落とし穴 
        11.4.3 チェックリスト 
        11.4.4 簡単な例 
        11.4.5 実体験 
    11.5 最初に移行するモジュールや機能をどう決めるか? 
        11.5.1 ベストプラクティスとパターン 
        11.5.2 トレードオフと落とし穴 
        11.5.3 チェックリスト 
        11.5.4 簡単な例 
        11.5.5 実体験 
    11.6  移行中にユーザー体験と一貫性を維持するにはどうすればよいか? 
        11.6.1 ベストプラクティスとパターン 
        11.6.2 トレードオフと落とし穴 
        11.6.3 チェックリスト 
        11.6.4 簡単な例 
        11.6.5 実体験 
    11.7 レガシーコードとの間で共有する依存関係とバージョンをどのように管理するか? 
        11.7.1 ベストプラクティスとパターン 
        11.7.2 トレードオフと落とし穴 
        11.7.3 チェックリスト 
        11.7.4 簡単な例 
        11.7.5 実体験 
    11.8 移行中に認証、ルーティング、状態などの横断的関心事をどのように管理するか? 
        11.8.1 ベストプラクティスとパターン 
        11.8.2 トレードオフと落とし穴 
        11.8.3 チェックリスト 
        11.8.4 簡単な例 
        11.8.5 実体験 
    11.9  マイクロフロントエンドに移行するにはマイクロサービスが必要か? 
        11.9.1 ベストプラクティスとパターン 
        11.9.2 トレードオフと落とし穴 
        11.9.3 チェックリスト 
        11.9.4 簡単な例 
        11.9.5 実体験 
    11.10 まとめ 

12章 モノリスからマイクロフロントエンドへ 
    12.1 コンテキスト 
        12.1.1 技術スタック 
        12.1.2 プラットフォームと主要なユーザーフロー 
        12.1.3 技術面の目標 
    12.2 移行戦略 
        12.2.1 マイクロフロントエンドの意思決定フレームワークの適用 
    12.3 SPAを複数のサブドメインに分割する 
    12.4 技術選定 
    12.5 実装の詳細 
        12.5.1 アプリケーションシェルの責務 
        12.5.2 アプリケーション初期化 
        12.5.3 通信ブリッジ 
        12.5.4 マイクロフロントエンドのマウントとアンマウント 
        12.5.5 状態の共有 
        12.5.6 グローバルルーティングとローカルルーティング 
        12.5.7 移行戦略 
        12.5.8 バックエンドの統合 
        12.5.9 マイクロフロントエンドにおける認証の統合 
        12.5.10 依存関係の管理 
        12.5.11 デザインシステムの統合 
        12.5.12 コンポーネントの共有 
        12.5.13 カナリアリリースの実装 
        12.5.14 ローカライズ 
    12.6 まとめ 

13章 マイクロフロントエンドの組織への導入 
    13.1 なぜマイクロフロントエンドを使うべきなのか? 
    13.2 データで課題を打開する 
    13.3 トレードオフ分析の作成 
        13.3.1 ビジネス要件 
        13.3.2 アーキテクチャ特性 
        13.3.3 組織の体制 
    13.4 組織とソフトウェアアーキテクチャの関係 
    13.5 How Do Committees Invent? 
    13.6 機能チームとコンポーネントチーム 
    13.7 コミュニケーションの流れを円滑にするガバナンス 
        13.7.1 RFC 
        13.7.2 アーキテクチャ決定レコード 
    13.8 コミュニケーションの流れを改善する手法 
        13.8.1 ワーキングバックワード 
        13.8.2 実践共同体とタウンホール 
        13.8.3 外部依存関係の管理 
    13.9 分権型組織 
    13.10 マイクロフロントエンドにおける分権化の影響 
        13.10.1 複雑さの高いサブドメイン 
        13.10.2 初期の作業負荷が高いサブドメイン 
        13.10.3 標準的な複雑さのサブドメイン 
        13.10.4 複雑さの低いサブドメイン 
    13.11 まとめ 

14章 AIとマイクロフロントエンド 
    14.1 アーキテクチャはまだ自動化できない 
    14.2 コンテキストエンジニアリングという解決策 
    14.3 現時点で実現可能なAIのユースケース 
        14.3.1 テスト 
        14.3.2 自動化 
        14.3.3 AIを活用したデバッグ 
        14.3.4 ダイアグラムの生成 
        14.3.5 READMEを常に最新の状態に保つ 
        14.3.6 プロトタイピング 
        14.3.7 プロジェクトのひな形の作成 
        14.3.8 コード最適化 
        14.3.9 エージェント型AIとの壁打ちでアイデアと代替案を探る 
        14.3.10 アクセシビリティ 
        14.3.11 コードの移行 
        14.3.12 AIで代替案を見つけ、前提を問い直す 
    14.4 AIと協働するためのコツ 
        14.4.1 ステップ1:達成したいことを明確にする 
        14.4.2  ステップ2:プロンプトを与えるだけでなく、コンテキストを設計する 
        14.4.3 ステップ3:開発者として普段どおりに考える 
        14.4.4 ステップ4:小さく焦点を絞った単位で反復する 
        14.4.5 ステップ5:出力をレビューし、リファクタリングする 
        14.4.6 ステップ6:AIを活用して自動化する 
    14.5 コードアシスタントとAIの限界 
        14.5.1 コード変更操作を理解する 
    14.6 AIとマイクロフロントエンドの未来 

索引