[** 概要]
 マイクロサービスの概念をフロントエンドに適用したもの
 一般的にマイクロサービスの考え方の多くは、バックエンドへ適用されることが一般的
 一方で、フロントエンドは依然モノリシックなままの状態
 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コンポーネントのイメージ
 開発チームづくり(バックエンドも含む)