マイクロフロントエンド の商品レビュー

Luca Mezzalira(著者),嶋田健志(訳者)

2023/04/29

■マイクロサービスの原則
１．ビジネスドメインのモデル化
２．自動化の文化
３．実装の詳細を隠す
４．ガバナンスの分散
５．独立デプロイ可能性
６．障害の分離
７．高い観測性

■アプリケーションシェル
　ロジック付きのシンプルなHTMLページをJavaScriptファイルでラップしたもの

■誤った抽象化によるコードの重複
　…DRY(don't repeat yourself)を「ソースコードのコピー＆ペーストをしてはいけない」と解釈してしまったのです。
　これもDRY原則の一部ですが、ほんの些細な一部でしかありません。DRY原則は「知識」や「意図」の二重化についての原則です。つまり、異なった場所（おそらくは全く異なった場所）に同じことを表現するという問題を避けるための原則です。

■コンポーネントとマイクロフロントエンドの違い
　コンポーネントとマイクロフロントエンドのどちらを構築すればよいか判断するかの良い経験則は、コンポーネントの場合、さまざまなユースケースに合わせて拡張し、さまざまなシナリオのすべてのユースケースをカバーするために複数のプロパティを公開する傾向があることです。一方、マイクロフロントエンドでは、ロジックカプセル化し、イベントによる通信を可能にします。

■コンポジションとオーケストレータとして垂直分割とアプリケーションシェルを使ったマイクロフロントエンド開発向けアーキテクチャ特性
デプロイ可能性　5/5
モジュール性　2/5
簡素性　4/5
テスト容易性　4/5
パフォーマンス　4/5
開発者体験　4/5
スケーラビリティ　5/5
全体管理　4/5

■webpackのモジュールフェデレーションを使ったマイクロフロントエンド開発向けアーキテクチャ特性
デプロイ可能性　4/5
モジュール性　4/5
簡素性　5/5
テスト容易性　4/5
パフォーマンス　4/5
開発者体験　5/5
スケーラビリティ　5/5
全体管理　3/5

■水平分割とiframeを使ったマイクロフロントエンド開発向けアーキテクチャ特性
デプロイ可能性　5/5
モジュール性　3/5
簡素性　3/5
テスト容易性　3/5
パフォーマンス　2/5
開発者体験　3/5
スケーラビリティ　5/5
全体管理　3/5

■Webコンポーネントを使ったマイクロフロントエンド開発向けアーキテクチャ特性
デプロイ可能性　4/5
モジュール性　3/5
簡素性　4/5
テスト容易性　4/5
パフォーマンス　4/5
開発者体験　4/5
スケーラビリティ　5/5
全体管理　3/5

■水平分割とサーバサイドコンポジションを使ったマイクロフロントエンド開発向けアーキテクチャ特性
デプロイ可能性　4/5
モジュール性　5/5
簡素性　3/5
テスト容易性　4/5
パフォーマンス　5/5
開発者体験　3/5
スケーラビリティ　3/5
全体管理　3/5

■水平分割とエッジサイドコンポジションを使ったマイクロフロントエンド開発向けアーキテクチャ特性
デプロイ可能性　3/5
モジュール性　4/5
簡素性　2/5
テスト容易性　3/5
パフォーマンス　3/5
開発者体験　2/5
スケーラビリティ　4/5
全体管理　3/5

■なぜマイクロフロントエンドを使うのか
・マイクロフロントエンドを使用すると、機能のイテレーションが高速化され、アプリケーション全体にバグが発生するリスクが軽減されることを指摘してください。
・日常業務のコンテキストと、マイクロフロントエンドがビジネス目標の達成に役立つ理由を調査して説明します。
・このパラダイムで解決しようとしている問題を一覧にしてください。
・コンテキストにマイクロフロントエンドを実装するための最良の方法を考えてください。
・このアーキテクチャがチームのコミュニケーションに与える影響を分析します。
・そのようなアーキテクチャを管理するための理想的なガバナンスを特定します。
・導入やテストまでの時間など、自動化パイプラインから指標を取得し、それらをどのように改善できるかを考えます。