Why micro-frontends?

前言

前篇 Micro Frontends では概念定義及び実装思路からマイクロフロントエンドとは何かを探求しましたが、マイクロフロントエンドを完全に理解するには、これらの問題を明確にする必要があります：

なぜマイクロフロントエンドが必要なのか？
マイクロフロントエンドは何を解決できるのか？コンポーネント化では解決できないのか？
マイクロフロントエンドは一体何をもたらしたのか？多技術スタックの並存？統一された技術スタックではダメなのか？

一.背景：なぜマイクロフロントエンドが必要なのか？

最初の HTML インラインスクリプトから、9102 年の数十万行の JavaScript コードまで、フロントエンドはますます重くなっています：

数 G のフロントエンドコードライブラリ
数百名のフロントエンド開発者
数 MB の Bundle Size

ますます複雑になっています：

次から次へと現れるフレームワーク、ライブラリ
様々な工程化体系
特色あるクロスエンド実践

したがって複雑さを分解し、協業効率を向上させ、柔軟な拡張をサポートするアーキテクチャパターンが必要となり、そこで、マイクロフロントエンドが舞台に登場しました

二.適用シナリオ：マイクロフロントエンドは何を解決できるのか？

マイクロフロントエンドの理念はマイクロサービスに類似し、膨大な全体を制御可能な小さなブロックに分解し、それらの間の依存関係を明確にします。

分割自治、多技術スタックの並存をサポートする方式を通じて、フロントエンドアプリケーションが直面する様々な問題を解決します：

業務モジュール間で日益に激化する結合をどのように治理するか？
開発チームをどのように分割、解��し、並行開発の目的を達成するか？
新しいフレームワーク、新しい方案をどのように既存の工程環境（構築ツールなど）に適応させるか？
古いフレームワークライブラリをどのように平穏にアップグレードするか？

業務機能に従って一塊のフロントエンドアプリケーションを一連のより小さく、より凝集したマイクロフロントエンドアプリケーションに分解し、同時に明確な交互プロトコルを通じてこれらのアプリケーション間の依存関係を管理し、異なる業務モジュールの解耦を実現します。そして各マイクロフロントエンドアプリケーションを独立チームに任せ、各自独立して開発し独立してデプロイし、並行性を十分に利用します

一方、多技術スタック並存能力の加持の下で、低コストで新しい技術実践を導入できるだけでなく、低リスクで製品の局部機能を置換することを許可し、依存項のアップグレード、アーキテクチャの交替、UI の改版などの重大な決定都能以漸進的な方式で平穏に落地できることを意味します：

分解：アプリケーションを一連の小型アプリケーション（子アプリケーション）で構成されるアプリケーションに拆分
置換：子アプリケーションを置換
組合：置換したものが調和して作業できることを保証

マイクロフロントエンドフレームワークを通じてアプリケーション間の主従関係を確立し（1 つのコンテナアプリケーション + n 個の子アプリケーション）、次に局部置換を行い、全て完了するまで行います。しかし、実践では通常リファクタリングと同時に新特性の継続的なイテレーションを保証する必要があるため、実際のフローは以下のようになる可能性があります：

抽象：一層の主従関係を追加、例えばフロントエンドルートを通じて制御
拡張：新規子アプリケーション
組合：元アプリケーションを直接一塊の子アプリケーションとして、新特性（新規の子アプリケーション）を持ってオンライン
リファクタリング：（時間上で拡張と並進可能）元アプリケーションを分解、置換

リファクタリングなどの作業を比較的長い時間跨度の下で制御可能な漸進的に完了させ、一刀切りのリソース要求と変更リスクを負担する必要はありません

コンポーネント化では解決できないのか？

The problems they're supposed to solve sound to me like they're already solved by a good component model. So is this solving an organizational issue rather than technical one? Such as if two teams can't agree on anything, even shared infra.

（I don't understand micro-frontends. から引用）

確かに、コンポーネント化でも分割自治を実現できます。例えば React では React.lazy + Suspense の方式で優雅にコード拆分を完了できます

しかしこれはコンポーネントモデルが統一（または技術スタックが一致）している前提の下で成り立ち、マイクロフロントエンドの半分のもう一つの優勢は単一技術スタックの制限を打破できることです：

They are microservices in the browser. Meaning separately built and deployed frontend apps that can choose their own framework and libs. The purpose is organizational scaling and avoiding framework lock-in.

これはコンポーネント化、モジュール化などの方案では満足できません。同様に、git submodule、npm module などの拆分方案も直接多技術スタック並存の能力を提供できません

三.意義：マイクロフロントエンドは一体何をもたらしたのか？

工程価値

半分はモジュール化がもたらす利点から、例えば：

開発効率の向上：多業務線の並行開発、チーム自治、独立イテレーション
交付コストの低減：アプリケーションレベルの機能复用
運用リスクの低減：変更範囲の縮小

もう半分は多技術スタック並存能力がもたらす利点から：

技術選択の増加：単一技術スタックに捆绑されなくなり、新しい技術、新しい交互モードの実験的試行錯誤に役立つ
复用性の強化：技術スタックの差異がもはや機能复用の障壁ではなく、第三者モジュールにとって特に重要
リファクタリングリスクの低減：低リスク局部置換、漸進的に大規模リファクタリングを完了

もちろん、多技術スタックの並存を許可することは、できるだけ多くの技術スタックを導入することを奨励する意味ではありません。より少ない技術スタックの方が通常基礎設施建設、リソース复用と経験共有により有利だからです

商業価値

マイクロフロントエンドの視点からの Web アプリケーションは一連の独立機能の組合です：

The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams.

（What are Micro Frontends? から引用）

したがって、マイクロフロントエンドアプリケーションはクラウドコンピューティングの背景下的クラウドサービスのように即取即用 でき、アプリケーションモジュールレベル（第三者）機能の接入/融合を実現し、その商業価値は：

細粒度、組合可能なフロントエンド製品形態：フロントエンド製品/能力をより細粒度、より柔軟な形態で出力（クラウドサービスのように必要に応じて自由組合）
マイクロフロントエンドアプリケーション生態：規範化されたマイクロフロントエンドアプリケーションは生態を形成でき、さらに小程序に類似したプラットフォーム体系を発生

参考資料

Micro Frontends
[I don't understand micro-frontends.](https://medium.com/ @lucamezzalira/i-dont-understand-micro-frontends-88f7304799a9)

前言