クライアントサイド(ES Module)でMicro Frontends
2021 年、あけましておめでとうございます。本年も宜しくおねがいします。最近、体重が増えてしまったため、有酸素運動を頑張っています。
本記事は、昨年の冬あたりから検証していた クライアントサイド統合での Micro Frontends について話そうと思います。検証したソースコードは、次のリポジトリにあります。
概要
全体設計イメージ図は、次のとおりです。
サーバーサイドは静的コンテンツを返すだけとし、クライアントサイドでアプリケーションを構築します。
構築手段は、ブラウザ標準である ES Module Import を使用し、アプリケーションに必要な Javascript(index.js, bootstrap 用)を load します。
UI に必要な各 Team の Component は、API 経由で取得し、レンダリングする構成になります。
Javascript Module
Javascript(index.js)には、次の Module を含めようと考えていました。
- DOM Parser
- 任意の要素の情報を取得する
- Imorter
- 任意の Module を取得する
- Router
- Web アプリケーション全体の Routing を管理する
- Worker
- バックグランドで実行する処理を管理する
- EventHub
- Module 間の通信を制御する
これらをざっと考えていた訳ですが、結局実装したのは Importer と Router ぐらいです (笑)。力尽きてしまいました。
また、前提として可能な限り各 Team の依存関係を独立するよう心がけます。Micro Frontends では、独立できてこそのメリットが享受できるため、できる限り各 Team の共通化は避けるようにします。
Javascript Importer
全体設計イメージ図にも書いていますが、Javascript の Importer は、Component Discovery API を通して、各 Team の Component を Import します。この構成は、Microservices の Service Discovery Patterns に似せています。この構成を取ることで、各チーム同士は独立(非依存)することができます。
Javascript Router
Router は、アプリケーション全体の Routing を管理します。例えば、/ は Top ページ、 /s は検索ページといった具合です。
Router には、後ほど説明する WebComponents との相性が良い vaadin/router を使用しました。
vaadin/router では、WebComponents を指定して Routing するため、指定された WebComponents は、Importer より取得します。
Component
Component は LitElement という WebComponents ベースのライブラリを使用しています。各 Team の Component(LitElement のライブラリ込)を Import していると、重複した load となりパフォーマンスがよろしくありません。共通ライブラリを事前に load (import map とかで)することをお勧めします。
WebComponents ということなので、Shadow DOM でレンダリングすることになります。CSS のスコープが独立できるため、他へ影響することはありません。ただ、全体的なブランドカラーを統一したい等 Design System がある場合、Component の共通化のやり方を(慎重に)考える必要があります。
Build Package, Design System, Performance Metrics
各 Team を独立したいといっても、共通化しないといけないことがあると考えています。私が想定しているものは、次のとおりです。
- Design System
- Component 全体のデザインを統一する
- Performance Metrics
- 計測指標のルールを全体で統一する
- Rendering Time
- Response Time
- etc
- 計測指標のルールを全体で統一する
- Build Package
- ライブラリの扱い方を統一する
- External
- ECM Version
- etc
- ライブラリの扱い方を統一する
と書いているだけで、実際に試した訳ではありません(笑)。
所感
Micro Frontends のサーバーサイド統合でもそうでしたが、Component を集約・提供するサービスは、クライアントサイド統合でも必要になりました。今回でいうと、Component Discovery API です。これは、Component 間の依存度を下げるためのレイヤーであり、Micro Frontends では、ほぼ必須の要素なのではないかと思います。
最後に
Micro Frontends は、統合パターンも大切ですが、もっと大切なのは、ドメインをどう分解するかだと思います。この分割が適切ではないとどうしても共通化しなければならないケースが誕生し、Micro Frontends のメリットが活かせないと思います。そろそろ、プロダクションレベルで検証したいと思いますが、中々重い腰を上げらない今日このごろです。
-
※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
関連する記事
タグ「フロントエンド」の記事
また、以下の記事の続きを書こうと思います。 https://silverbirder.github.io/blog/contents/20260312/ ビジネスロジック アプリケーションのビジネスロジックに関することについて書きます。 複
2026年03月18日
Webフロントエンドのコードレビューをしているときに考えていることについて書きます。 毎日1記事投稿、1記事30分という制約を課していますので、本記事は完璧ではありません。(言い訳) また希望的な考えもあるので、実践していないものもあります
2026年03月12日
AI にコードを書かせた後、余計なコードを見つけて消す作業があります。 不毛なことなので、それらの作業を減らすためのお作法を紹介します。 未使用コードを消す 以下でも書きましたが、未使用コードの検査に knip を使うことが多いです。 ht
タグ「成果物」の記事
個人サイトリニューアルを機に、記事を書く執筆環境Webアプリを用意しました。 https://silverbirder.github.io/blog/contents/20260128/ どのようなものか簡単に紹介します。 入力とプレビュー
2026年02月20日
個人サイト（ジブンノート）をリニューアルしました。本記事では、個人サイトをリニューアルした際にあった出来事などを振り返りたいと思います。ちなみに、個人サイトは以下のページです。ノート風デザインで、ブログ記事が読めるようになりました！🎉
個人サイトをリニューアルしました！🎉 https://silverbirder.github.io リニューアルは、今回で6回目です。制作期間は、去年の12月27日から今年の1月28日までの約1ヶ月間です。個人的には最速の開発期間でした。AIの力は偉大ですね。本記事では、個人サイトのリニューアルでこだわったポイントについて紹介します。
2026年01月28日