多くの開発者はマイクロサービス・アーキテクチャを知っていますが、マイクロ・フロントエンドはあまり知られていません。名前が示すように、マイクロ・フロントエンドは、マイクロサービスと概念が似ています。モノリシック・アプリケーションと同じ問題の多くを解決しようとします。大きすぎて、作業が難しく、変更も困難です。新しい人材のオンボーディングは、困難な場合があります。また、複数のチームがアプリケーションのさまざまな部分で作業している場合は、全ての変更を互いに調整する必要があります。
マイクロサービスは、バックエンドをより独立したサービスに分割するのに役立ちます。同じアプローチを使用して、シングル・ページ・アプリケーション（SPA）を小さなアプリケーションに分割できます。また、異なるパーツを元に戻すことができるオーケストレータを追加する必要があり、ユーザーがSPAの動作を経験し続けます。
マイクロ・フロントエンド・アーキテクチャの代替手段
もちろん、コードの一部を独自の npm パッケージに分割するなど、大規模なアプリケーションの望ましくない側面に対処する方法は他にもあります。これにより、レポが大きすぎるなど、問題の一部を解決できます。例えば、Angular では、コードをモジュールに分けることもできます。これにより、アプリケーションをある程度垂直に分割することができます。しかし、依存関係の 1 つが更新されたときにトップレベルのプロジェクトを構築しなければならないといった欠点もあります。また、開発者の経験もそれほど優れていません。どのようなフレームワークを使用する場合でも、全てを同じバージョンにアップグレードすることをお勧めしますが、それは大きな作業であり、誰も進んでやりたがりません。また、複数のアプリケーションを iframe 経由で結合することもできます。独立しているが、アプリケーション間のコミュニケーションが問題であり、コードやスタイルの共有なども問題であるため、独立しすぎる可能性があります。
「マイクロ・フロントエンドによる救済」とは
マイクロ・フロントエンドは、これら 2 つのアプローチの組み合わせです。各マイクロ・フロントエンドは、SPA と比較して個別のアプリケーションです。リンクされたスクリプトとスタイル・ファイルで index.html にコンパイルされるのではなく、JavaScript モジュールにコンパイルされます。「メイン」アプリの iframe ではなく、コードは、URL が何らかのパターンに一致すると、モジュールがレイジーロードされ、特定の場所に配置されることを定義します。このため、同じページに複数のアプリケーションを配置し、相互に相互接続することができます。
そのため、マイクロ・フロントエンドは、メイン・アプリケーションでのみ処理できるアプリケーション・レイアウトや基本的な CSS ルールを処理する必要はありません。同じバージョンの React を使用して複数のマイクロ・フロントエンドを持つ場合は、React モジュールを共有してもらうこともできます。マイクロ・フロントエンドごとに個別にダウンロードする必要はありません。JS モジュールの異なるバージョンを持つことも問題ではありません。
マイクロ・フロントエンドの主な懸念事項は、アプリケーションの他の部分にスタイルがオーバーフローしないようにすることです。幸いなことに、一般的に使用される UI フレームワークには、それを容易に処理するためのツールがあります。
マイクロ・フロントエンド・アーキテクチャのためのツール
マイクロ・フロントエンド・アプリケーションをロードするために独自のコードを記述するのは、かなりの作業です。幸いなことに、オーケストレーションを処理し、最も人気のあるフレームワークで書かれたアプリケーションをマイクロフロント・エンド形式に変換するためのツールを提供する複数のフレームワークがあります。
ピュア・ストレージでは、single-spaを選択しました。主なメリットは、分かりやすく、JSフレームワークを幅広くサポートし、詳細なドキュメントを作成できることです。さらに、single-spa は、複数のタイプのマイクロ・フロントエンドを提供し、それぞれがわずかに異なるジョブに適しています。
現時点では、「アプリケーション」タイプのみを使用しています。これは、SPAからマイクロ・フロントエンドへの移行に最も使いやすいためです。その他のタイプでは、より詳細なマイクロ・フロントエンド・アーキテクチャも必要です。また、「アプリケーション」は、シングルスパの作成者のデフォルトとして推奨されます。
