マイクロフロントエンドについてまとめてみた
[** 概要]
マイクロサービスの概念をフロントエンドに適用したもの
一般的にマイクロサービスの考え方の多くは、バックエンドへ適用されることが一般的
一方で、フロントエンドは依然モノリシックなままの状態
ECサイトのようなWebアプリケーションでは、様々な専門知識(商品情報、注文、検索など)が必要とされる為、フロントエンドがモノリシックだと担当範囲がとても広くなる
上記を解消する為のアーキテクチャがマイクロフロントエンド
全体がモノリシック、フロントエンド&バックエンドの完全分離、BEだけがマイクロサービス
マイクロフロントエンドを適用した全体図
※ https://micro-frontends-japanese.org
バックエンドだけでなく、バックエンド〜フロントエンドまでをマイクロサービス化するということ
IKEA, Zalando, はマクロフロントエンドを採用するケースが多い
Amazonもマイクロフロントエンドで取り組んでいる様子
Spotifyのようなサービスにも適用されるケースがある
日本ではマイクロフロントエンドの導入実績が少なく、まだまだ発展途上
最も良いものという訳ではなく、他のアーキテクチャ同様相応のメリット、デメリットが存在するもの
[** 根底にある考え]
テクノロジーとの分離
各チームは実装で利用する技術を他チームとの調整をせずに選択出来るべき
チームをまたいでコードを共有しない
たとえ扱っている技術が同じでもコードを共有してはいけない
それ自身で完結しているアプリケーションを作る
共有の状態やグローバルの変数に依存してはいけない
[** メリット]
任意のテクノロジーを任意のチームで開発可能
特定の機能をE2Eで確実に実行可能
特定のドメインについて最高の知識を持つチーム間で作業を分散できると、リリースプロセスが確実にスピードアップ
リグレッションテストがモノリシックより遥かに小さい
特定の機能だけに集中できる
[** デメリット]
ドメインが適切に分割出来ていない場合、相互接続するチームが存在することになる
重複作業の発生
特定チームが改善しても、全体チームが改善しにくい
あるチームがwebpackビルドの時間短縮に成功しても、他のチームは影響を受けない
ライブラリのセキュリティパッチの適用等も時間がかかる上に、漏れが発生するリスクがある
一部ではNext.js、一部ではRemix、一部ではNuxt.jsの様に、異なる技術が各所で採用された時に、チーム間を横断した開発が難しくなる
クロスアプリケーション通信の複雑化
例:商品購入→買い物かごの数値動的変更
運用の難しさ、チーム全体へ共有する仕組みを考えることが必要
デザインシステム
パフォーマンス
ナレッジ
[** 自分メモ]
共通利用している部分の運用方法が課題
ページ毎にNext.js環境を作成
共通利用コンポーネントをnpm, yarnでinstall, import利用できる仕組み化
共通利用コンポーネントは、CRAやViteで作成されたReactコンポーネントのイメージ
開発チームづくり(バックエンドも含む)