クライアントサイド(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 のメリットが活かせないと思います。そろそろ、プロダクションレベルで検証したいと思いますが、中々重い腰を上げらない今日このごろです。

-

読者になる

|

シェアする

|

ブログを応援する

この記事がよかったら、お布施という形で応援してもらえるとうれしいです。

おふせぼたん

関連する記事

タグ「フロントエンド」の記事

モジュールアップデートでやっていること

ITヲタクな AI くんにピッタリな仕事の一つは、モジュールアップデート。 特に、メジャーアップデートが超助かる。 昔だったら 数ヶ月掛かった移行も、数日たらずに対応できるようになったので、 さすが ITヲタクくん。 対応してよかったフロー

2026年07月24日

AI

フロントエンド

写経テストコードを全部消した

以下で書いた通り、プロダクトコードを写経したテストコードを削除しました。 "こぶりー" ( https://kobliy.vercel.app/ ) という個人ブログを読むアプリのコードです。 https://silverbirder.gi

2026年06月08日

AI

フロントエンド

テスト

念の為に、手動確認をしよう

最近のお悩みは、Webのソフトウェア開発におけるテストコードが爆増したことにより、 テスト成功による過度な安心感 によって手動確認するのが減っているのかもと思ったりしています。 例えば、Webのフォーム画面に小さな改修があったとして、その修

2026年06月03日

AI

フロントエンド

タグ「成果物」の記事

GitHub Busy をアラームの様に登録したい

仕事柄、GitHub Busy を設定しています。 この Busy には有効期限を GUI 上で登録することができます。 GitHub Busy 編集画面 困っていること 毎週水曜日に Busy を設定していて、木曜日に解除しています。 こ

2026年06月19日

成果物

個人ブログを読むアプリ、こぶりーをリリースしました！

個人ブログ好きの皆さんに朗報です！ "個人ブログを、見つけて、読んで、シェアする" アプリ、こぶりーをリリースしました！🎉 こぶりー アプリのURLは、以下の通りです。 こぶりー - kobliy.vercel.app こちらから、個人ブ

2026年05月23日

成果物

趣味

記事投稿 連続100回以上している 私専用執筆環境Webアプリ

個人サイトリニューアルを機に、記事を書く執筆環境Webアプリを用意しました。 https://silverbirder.github.io/blog/contents/20260128/ どのようなものか簡単に紹介します。 入力とプレビュー

2026年02月20日

成果物

← ブログ一覧へ