Micro Frontends を調べたすべて

観点	内容
独立性	・任意のテクノロジーと任意のチームで開発可能 /
展開	・特定の機能をエンドツーエンド(バック、フロント、デプロイ）で確実に実行可能
俊敏性	・特定のドメインについて最高の知識を持つチーム間で作業を分散すると、リリースプロセスが確実にスピードアップして簡素化される。 / ・フロントエンドとリリースが小さいということは、リグレッションテストの表面がはるかに小さいことを意味する。リリースごとの変更は少なく、理論的にはテストに費やす時間を短縮できる。 / ・フロントエンドのアップグレード/変更にはコストが小さくなる

観点

内容

独立性

・任意のテクノロジーと任意のチームで開発可能 /

展開

・特定の機能をエンドツーエンド(バック、フロント、デプロイ）で確実に実行可能

俊敏性

・特定のドメインについて最高の知識を持つチーム間で作業を分散すると、リリースプロセスが確実にスピードアップして簡素化される。 / ・フロントエンドとリリースが小さいということは、リグレッションテストの表面がはるかに小さいことを意味する。リリースごとの変更は少なく、理論的にはテストに費やす時間を短縮できる。 / ・フロントエンドのアップグレード/変更にはコストが小さくなる

Cons

観点	内容
独立性	・独立できず、相互接続しているチームが存在しがち / ・多くの機能で複数のマイクロフロントエンドにまたがる変更が必要になり、独立性や自律性が低下 / ・ライブラリを共有すること自体は問題ないが、不適切な分割によって作成された任意の境界を回避するための包括的な場所として使用すると、問題が発生する。 / ・コンポーネント間の通信の構築は、実装と維持が困難であるだけでなく、コンポーネントの独立性が取り除かれる / ・横断的関心事への変更ですべてのマイクロフロントエンドを変更することは、独立性が低下する
展開	・より大きな機能の部分的な実装が含まれているため、個別にリリースできない / ・サイト全体の CI / CD プロセス
俊敏性	・重複作業が発生する / ・検出可能性が低下した結果、一部の標準コンポーネントを共有できず、個別のフロントエンド間で実装が重複してしまう。 / ・共有キャッシュがないと、各コンポーネントは独自のデータセットをプルダウンする必要があり、大量の重複呼び出しが発生する。
パフォーマンス	・マイクロフロントエンドの実装が不適切な場合、パフォーマンスが低下する可能性がある。

観点

内容

独立性

・独立できず、相互接続しているチームが存在しがち / ・多くの機能で複数のマイクロフロントエンドにまたがる変更が必要になり、独立性や自律性が低下 / ・ライブラリを共有すること自体は問題ないが、不適切な分割によって作成された任意の境界を回避するための包括的な場所として使用すると、問題が発生する。 / ・コンポーネント間の通信の構築は、実装と維持が困難であるだけでなく、コンポーネントの独立性が取り除かれる / ・横断的関心事への変更ですべてのマイクロフロントエンドを変更することは、独立性が低下する

展開

・より大きな機能の部分的な実装が含まれているため、個別にリリースできない / ・サイト全体の CI / CD プロセス

俊敏性

・重複作業が発生する / ・検出可能性が低下した結果、一部の標準コンポーネントを共有できず、個別のフロントエンド間で実装が重複してしまう。 / ・共有キャッシュがないと、各コンポーネントは独自のデータセットをプルダウンする必要があり、大量の重複呼び出しが発生する。

パフォーマンス

・マイクロフロントエンドの実装が不適切な場合、パフォーマンスが低下する可能性がある。

統合パターン

統合	選択基準	技術
サーバーサイド統合	良好な読み込みパフォーマンスと検索エンジンのランキングがプロジェクトの優先事項であること	・Podium / ・Ara-Framework / ・Tailor / ・Micromono / ・PuzzleJS / ・namecheap/ilc
エッジサイド統合	サーバーサイド統合と同じ	・Varnish EDI / ・Edge Worker / / CDN / ・ Akamai / ・ Cloudfront / ・ Fastly / ・CloudFlare / ・ Fly.io
クライアント統合	さまざまなチームのユーザーインターフェイスを 1 つの画面に統合する必要があるインタラクティブなアプリケーションを構築すること	・Ajax / ・Iframe / ・Web Components / ・Luigi / ・Single-Spa / ・FrintJS / ・Hinclude / ・Mashroom
ビルド時統合	他の統合が非常に複雑に思われる場合に、 / 小さなプロジェクト（3 チーム以下）にのみ使用すること	・ Bit.dev / ・ Open Components / ・ Piral

統合

選択基準

技術

サーバーサイド統合

良好な読み込みパフォーマンスと検索エンジンのランキングがプロジェクトの優先事項であること

・Podium / ・Ara-Framework / ・Tailor / ・Micromono / ・PuzzleJS / ・namecheap/ilc

エッジサイド統合

サーバーサイド統合と同じ

・Varnish EDI / ・Edge Worker / / CDN / ・ Akamai / ・ Cloudfront / ・ Fastly / ・CloudFlare / ・ Fly.io

クライアント統合

さまざまなチームのユーザーインターフェイスを 1 つの画面に統合する必要があるインタラクティブなアプリケーションを構築すること

・Ajax / ・Iframe / ・Web Components / ・Luigi / ・Single-Spa / ・FrintJS / ・Hinclude / ・Mashroom

ビルド時統合

他の統合が非常に複雑に思われる場合に、 / 小さなプロジェクト（3 チーム以下）にのみ使用すること

・ Bit.dev / ・ Open Components / ・ Piral

Web サイト ⇔Web アプリ

マイクロフロントエンドは、かなりのオーバーラップがあるバンドの中央部分の大部分に最も適しています。バンドの両極端に該当するプロジェクトにマイクロフロントエンドアーキテクチャを実装しようとすると、生産性に反するそうです。

リポジトリ

パターン	Pros	Cons	技術
モノリポ	コードベース全体に簡単にアクセスできる。 / (検出可能性が高い)	モノリポジトリは、特に大規模なチームで作業しているときに、 / 動作が遅くなる傾向があり、バージョン管理下のコミットとファイルの数が増加する。	・nx.dev / ・lerna
マルチリポ	・マルチリポジトリは、非常に大規模なプロジェクトと / それに取り組む非常に大規模なチームがある場合に最適。	マルチリポジトリ環境では、各マイクロアプリを / 個別にビルドする必要がある。

パターン

Pros

Cons

技術

モノリポ

コードベース全体に簡単にアクセスできる。 / (検出可能性が高い)

モノリポジトリは、特に大規模なチームで作業しているときに、 / 動作が遅くなる傾向があり、バージョン管理下のコミットとファイルの数が増加する。

・nx.dev / ・lerna

マルチリポ

・マルチリポジトリは、非常に大規模なプロジェクトと / それに取り組む非常に大規模なチームがある場合に最適。

マルチリポジトリ環境では、各マイクロアプリを / 個別にビルドする必要がある。

アーキテクチャ名	関係リンク
Modular Monolith	・Deconstructing the Monolith – Shopify Engineering / ・kgrzybek/modular-monolith-with-ddd
Enterprise Architecture (Clean Architecture)	・Building an Enterprise Application with Vue / ・soloschenko-grigoriy/vue-vuex-ts
Jam Stack	Jam Stack
App Shell	App Shell モデル

アーキテクチャ名

関係リンク

Modular Monolith

・Deconstructing the Monolith – Shopify Engineering / ・kgrzybek/modular-monolith-with-ddd

Enterprise Architecture (Clean Architecture)

・Building an Enterprise Application with Vue / ・soloschenko-grigoriy/vue-vuex-ts

Jam Stack

App Shell

App Shell モデル