Micro Frontends を学んだすべて
Micro Frontends という Web フロントエンドアーキテクチャがあります。 このアーキテクチャを知るために、書籍を読み、簡単なサンプル Web アプリを開発しました。 そこから学んだことをすべて議事録として残したいと思います。
モノリシックな Web アプリケーション
マイクロサービスという考え方の多くは、バックエンドへ適用されることが一般的です。 一方で、フロントエンドは依然モノリシックなままの状態です。
EC サイトのような Web アプリケーションでは、様々な専門知識(商品、注文、検索など)を必要とし、フロントエンド開発者の守備範囲がとても広くなってしまいます。 開発者には限界があり、いつしか トラブルシューティングに追われる日々 になってしまいます。
そこで、Micro Frontends というアーキテクチャの出番です。
Micro Frontends とは
それはマイクロサービスの考え方をフロントエンドに拡張したものです。
※ https://micro-frontends-japanese.org
要は、バックエンドだけでなく、バックエンドからフロントエンドまでをマイクロサービス化することです。
さらに詳しく知りたい方は、次のページをご参考下さい。とてもわかりやすいです。
また、次の書籍を読むと、 https://www.manning.com/books/micro-frontends-in-action
Amazon does not talk a lot about its internal development structure. However, there are reports that the teams who run its e-commerce site have been working like this for a long time. ... Micro frontends are indeed quite popular in the e-commerce sector. ** In 2012 ** the Otto Group, a Germany based mail order company and one of the world’s largest e-commerce players started to split up its monolith. ... The Swedish furniture company IKEA and Zalando , one of Europes biggest fashion retailers, moved to this model. ... But micro frontends are also used in other industries. Spotify organizes itself in autonomous end-to-end teams they call Squads. ...
Excerpt From: Michael Geers. “Micro Frontends in Action MEAP V03.” iBooks.
という内容があります。
IKEA や Zalando といった EC サイトが Micro Frontends を採用する ケースが多く、公には言っていませんが、Amazon も Micro Frontends で取り組んでいるようです。 EC サイトだけでなく、Spotify のようなサービスにも適用されるケースがあります。
Micro Frontends の良さ
私が思う Micro Frontends から得られる最大の恩恵は、" 局所化 " だと思います。
フロントエンドをサービス毎(商品、注文、検索など)に分割することで
- サービスの 専門性 向上
- ex. 対象サービスのフロントエンドだけに集中できる
- サービスの 開発速度 向上
- ex. 対象サービスのソースコードだけ読めば良い
- ex. 対象サービスだけにライブラリアップデートすれば良い
- ex. フレームワークの切り替えは対象サービスだけすれば良い
少し薄っぺらいかも知れませんが、↑ のように実感しています。
※ Micro Frontends は Web ベースのアーキテクチャになります。
Micro Frontends の難しさ
ここは、まだちゃんと掘り下げれていませんが、次のようなものがあります。
- 特定チームが改善しても、チーム全体が改善しない
- ex. あるチームが webpack のビルド時間短縮に成功しても、他のチームは影響を受けない
- ex. 全てのチームが採用しているライブラリのセキュリティパッチは、それぞれのチームが更新しなければならない
- チーム全体へ共有する仕組みを考える必要がある
- ex. デザインシステム、パフォーマンス、ナレッジ
- エッジな技術スタック採用は、チームメンバー移動を困難にする
- ex. パラダイムシフトが発生してしまう 技術スタック
Micro Frontends の作る上で考えること
フロントエンドをマイクロサービス化するということは、各サービスで HTML/CSS/JS を作ることになります。 それらの サービスを統合するサービス が重要になってきます。
大きく分けて 2 つの統合パターンがあります。
| 種類 | 解決手段 | メリット | デメリット |
|---|---|---|---|
| サーバーサイド統合 | SSI, ESI, Tailor, Podium | ・SEO 対策上良い / ・ユーザーのネットワークレイテンシーが少ない / ・初回ロードパフォーマンスが優れている | ・インタラクションアプローチが不得意 |
| クライアントサイド統合 | ・Web 標準 / ・シャドウ DOM による堅牢な作り | ・サポートブラウザに依存する / ・クライアント側の JavaScript が有効であること |
また、これら 2 つの選択基準は次のようになります。
| 種類 | 選択基準 |
|---|---|
| サーバーサイド統合 | 良好な読み込みパフォーマンスと検索エンジンのランキングがプロジェクトの優先事項であること |
| クライアントサイド統合 | さまざまなチームのユーザーインターフェイスを 1 つの画面に統合する必要があるインタラクティブなアプリケーションを構築すること |
今回、私はサーバーサイド統合(Podium)を選択しました。 ただ、インタラクティブなアプローチも必要だったため、 Hydration を使いました。
Hydration refers to the client-side process during which Vue takes over the static HTML sent by the server and turns it into dynamic DOM that can react to client-side data changes.
※ https://ssr.vuejs.org/guide/hydration.html
Hydration は、サーバーサイドでレンダリングした静的 HTML に、クライアントサイドの動的レンダリングができるようにするようなものです。
※ クライアントサイド統合(Web Components)でも良かったのですが、私都合により却下となりました。
Micro Frontends サンプル Web アプリ
apple, banana, orange という商品を検索するだけのサンプル Web アプリを作りました。
概要図はこちらです。
サンプルコードは、ここに置いています。 https://github.com/silverbirder/micro-frontends-sample-code
サービス
| サービス | 役割 | JS フレームワーク |
|---|---|---|
| team-search | 商品を検索するサービス | Vue.js |
| team-product | 商品を表示するサービス | React.js |
| team-page | サービスを統合するサービス | フレームワーク未使用 (Node.js) |
仕組み
Podium というライブラリを採用しました。
これは、フロントエンドのサービスを簡単に統合できるようなライブラリになっています。 Podium には大きく分けて 3 つの機能があります。
- @podium/podlet
- ページフラグメントサーバーを構築する
- ex. team-search, team-product
- @podium/layout
- Podlet を集めて、ページ全体のレイアウトを構築する
- ex. team-page
- @podium/browser
- ブラウザベースの機能を提供する
- MessageBus による Podlet 同士のコミュニケーション
- ex. team-search, team-product で publish/subscribe
@podium/podlet
Podlet には、manifest.json と呼ばれる値を返却することが必須になっています。 menifest.json には、サービスのエンドポイントや、Asset(JS や CSS)のパスが明記されています。
team-search では
curl https://team-search.fly.dev/manifest.json | jq .
{
"name": "search",
"version": "1.0.0",
"content": "/",
"fallback": "",
"assets": {
"js": "/search/static/fragment.js",
"css": ""
},
"css": [],
"js": [
{
"value": "/search/static/fragment.js",
"async": true,
"defer": true,
"type": "default"
}
],
"proxy": {}
}というレスポンス結果になります。
@podium/layout
Layout では、Podlet の manifest.json の定義に従って fetch することになります。
team-page では
// server.js (express)
app.get(`/`, async (req, res) => {
const incoming = res.locals.podium;
const [searchBox] = await Promise.all([
podletSearch.fetch(incoming, { pathname: "/search/box", query: req.query }),
]);
const [items] = await Promise.all([
podletProduct.fetch(incoming, {
pathname: "/product/items",
query: { id: searchBox.headers["x-product-items"] },
}),
]);
res.podiumSend(`
<html>
<head>
<title>Shop</title>
${searchBox.js.map((js) => js.toHTML())}
${items.js.map((js) => js.toHTML())}
</head>
<body>
<div id="app-shell">
${searchBox.content}
${items.content}
</div>
</body>
</html>
`);
});のように Podlet を使って、ページ全体を構築します。このようにサーバーサイドで統合しています(SSR)。 しかし、インタラクティブなアクションも必要なため、Podlet から Hydrate するための js を読み込んでいます。
また、team-search の検索結果(x-product-items)を team-product へ渡しているため、商品の検索結果を含めて SSR が実現できます。
@podium/browser
サーバーサイドは、podium/podlet, podium/layout で連携できます。 クライアントサイドは、この @podium/browser の MessageBus で連携できます。
今回のサンプル Web アプリでは、次のようなユースケースに使用しています。
- ユーザーが検索ボックスにキーワードを入力する
- team-search がキーワードから商品を検索する
- team-search が 2 の結果を publish する
- team-product が 3 を subscribe し、商品を更新する
// team-search.js
messageBus.publish("search", "search.word", { items: hitItems });// team-product.js
messageBus.subscribe("search", "search.word", (event) => {
hydrate(
<Items {...{ items: event.payload.items }} />,
document.querySelector("#team-product-items")
);
});このようにすることで、画面更新ではなく部分更新ができました。 インタラクティブな操作も実現可能です。
状態管理, ルーティング
ここは、まだきちんと作っていませんが、次のようなコンセプトで設計するのが良いと思います。
- 状態管理
- 各サービスが状態管理する。状態は共有しない。
- 統合サービスが共通的な状態を管理する。
- ルーティング
- 各サービスが query を設定する。
- 統合サービスが URL パスを管理する。
その他
各サービスは、fly.io という PaaS へデプロイしています。
CDN で SSR が実行できる Edge Worker を使用しています。 これにより、SSR 結果をキャッシュし、高速にレスポンスを返却できます。
ただ、サンプル Web アプリでは、全くその力を引き出せていないです...
※ 参考記事 https://mizchi.hatenablog.com/entry/2019/02/21/235403
サンプル Web アプリで分かったこと
SSR + CSR (Hydration) が実現可能
サーバーサイド統合であっても、CSR は実現可能 です。 ただし、Hydration には パフォーマンス面に難有り なため、このあたりは課題として残ります。 また、CSR するための bundle した javascript の size には注意が必要です。
例えば、次のリポジトリにある "shared_vendor_webpack_dll" のように、vendor ファイルを共有することで、 javascript の size を減らすといった手段があります。
また、次のリポジトリにある zalando tailor は、script load を streaming することで、 全体の script load 完了時間を短縮するツールもあります。
サービス内で技術スタックを選択できる
マイクロサービスでは、よくあるメリットとして挙げられるものです。 フロントエンドでも、同様に技術スタックを自由に選択できます。
今回では、React.js と Vue.js を使用しています。 これを Riot.js や Svelte.js にも切り替えることも可能です。
フロントエンド界隈では、JS フレームワークの変化が激しい ので、 このメリットは大切だと思います。
ただし、Podium の manifest.json を返却しなければなりません。 今の所、Podium に対応しているのは Express のみなので、Express を使用する フレームワークのみとなります。
サービス毎のフロントエンドに集中できる
検索サービスだと、検索に特化したフロントエンドのみに集中することができます。 商品サービスだと、商品の表示内容のみに集中することができます。
ただ、どうしても他サービスと連携する要件が出てきます。 これは、マイクロサービスとしての難しさだと思います。 例えば、各サービスがどのタイミングでイベント登録するのかを考える必要があります。
最後に
EC サイトのようなアプリケーションでは『商品を探しやすくする』『買いたくなるような商品を表示する』 『商品を簡単に購入できる』などフロントエンドでやるべきことが多くあります。
そういうサービスにおけるフロントエンドがモノリシックであれば、 統一性が欠けてしまったり、知らぬ間にバグを埋め込んでしまうケースが発生してしまいます。
Micro Frontends は、このような 複雑化するフロントエンドにメスを入れる良いアーキテクチャ だと思います。 ただし、バックエンドにおけるマイクロサービス化による課題があるように、フロントエンドにおける マイクロサービス化にも課題はあるはずです。
日本では、Micro Frontends の導入実績が少なく、まだまだ発展途上だと思います。 この記事が、どこかのサービスへの参考になればと思います。
最後まで読んで頂き、ありがとうございました。
参考リンク
-
シェアする
フォローする
購読する
関連する記事
タグ「フロントエンド」の記事
AI にコードを書かせた後、余計なコードを見つけて消す作業があります。 不毛なことなので、それらの作業を減らすためのお作法を紹介します。 未使用コードを消す 以下でも書きましたが、未使用コードの検査に knip を使うことが多いです。 ht
最近、iframeを使っています。 クライアントサイドで埋め込む想定で、iframeを使おうとしています。 色々と苦労したことがあったので、書いて残しておこうと思います。 レスポンスヘッダー 前提として、ウェブアプリケーションをプロダクショ
紙を積んだイラストをSVGで書こうとしていました。 （当たり前ですが）図形を表現するためには数学の知識が必要で、学生の頃の記憶を思い出したので疲れました。 所感について、諸々書こうと思います。 成果物 実際に完成したのは、以下の画像ができま
2026年02月17日