🦁

マイクロフロントエンドとは

2021/06/06に公開

要約

Webサイト・Webアプリケーションの特定のUIや機能を、単体で実行可能な単位でモジュールに切り出し、それらを組み合わせて実行するアーキテクチャの一種。
開発者が他のコードやチーム、開発サイクルへの影響を考えず、場合によっては独自のフレームワークを採用し、開発を行うことができるようになります。

実現方法

マイクロフロントエンドの要約を見て、真っ先に持つ疑問は「どうやって1つのサイト・アプリケーションとして実行させるのか?」ではないでしょうか。その実現方法に当たるものが統合アプローチです。

引用: https://martinfowler.com/articles/micro-frontends.html

コンテナアプリケーションとマイクロフロントエンドのモジュールは別のサーバーに置かれます。
コンテナアプリケーションに対してリクエストが送られると、他のマイクロフロントエンドのサーバーにリクエストを送り、各UIや機能を取得し、1つのページに統合します。
統合する方法は主に下記のようになります。

JavaScriptによりランタイム時に統合する
各マイクロフロントエンドモジュールをスクリプトとして読み込みます。柔軟な対応が可能などの理由で最も一般的な方法になっています。
ビルド時に統合する
各マイクロフロントエンドモジュールをパッケージとして公開し、コンテナアプリケーションでそれらを依存関係として使用します。
Webコンポーネントを介して、ランタイム時に統合する
Webコンポーネントでカスタム要素を組み込むことも可能です。
サーバーサイドでのテンプレート構成
URLに基づいて、サーバー側でHTMLを出し分ける。
iframe
iframeもマイクロフロントエンドの一つと言えますが、セキュリティなどに問題があるので、推奨されません。

「JavaScriptによりランタイム時に統合する」場合、一例として以下のようになります。

<html>
  <head>
    <title>Feed me!</title>
  </head>
  <body>
    <h1>Welcome to Feed me!</h1>

    <!-- These scripts don't render anything immediately -->
    <!-- Instead they attach entry-point functions to `window` -->
    <script src="https://browse.example.com/bundle.js"></script>
    <script src="https://order.example.com/bundle.js"></script>
    <script src="https://profile.example.com/bundle.js"></script>

    <div id="micro-frontend-root"></div>

    <script type="text/javascript">
      // These global functions are attached to window by the above scripts
      const microFrontendsByRoute = {
        '/': window.renderBrowseRestaurants,
        '/order-food': window.renderOrderFood,
        '/user-profile': window.renderUserProfile,
      };
      const renderFunction = microFrontendsByRoute[window.location.pathname];

      // Having determined the entry-point function, we now call it,
      // giving it the ID of the element where it should render itself
      renderFunction('micro-frontend-root');
    </script>
  </body>
</html>

メリット

1. 分離されたコードベース

機能改修などを行う際に、開発者が他のページや機能のデグレーションなどを気にする範囲が減るため、開発者の負担を減らすことができます。

2. 高速なビルド

アプリケーションが大きくなるほど、ビルドに時間がかかるようになります。マイクロフロントエンドでモジュールごとのビルドパイプラインを構築すれば、それぞれのビルドは高速になり、CI上でも扱いやすくなります。

3. 独立したデプロイ

ソースコードが分かれているため、個々にデプロイすることが可能で、機能ごとのリリースサイクルを早めることに繋がります。

4. アップグレード

モノシリックなアプリケーションの場合、全体で使用しているフレームワークをアップグレードするのは、コストがかかる作業でした。しかし、マイクロフロントエンドを採用していれば、フレームワークなどを徐々にバージョンアップすることが可能で、バージョンアップの際のコストを抑えられます。

5. 自立したチーム

上記のメリットより、機能ごとにチームを分離することが容易になります。
チームの規模が大きくなりすぎないことで、個々の機能の開発速度上昇にもつながります。

デメリット

1. モジュール間の依存・干渉

マイクロフロントエンドのモジュールは、分離または疎結合の状態で開発されるべきですが、グローバルCSSやSSOなどで依存や干渉などが発生した場合、デバッグが難しくなる場合があります。

2. パフォーマンスへの影響

複数のマイクロフロントエンドモジュールがReactを使用している場合、モジュールの数だけ重複してReactがバンドルに含まれるため、バンドルサイズやメモリ消費量が増加します。
また、マイクロフロントエンドモジュールを動的、もしくは遅延ロードすることも影響があります。

3. テスト

コンテナアプリケーションとマイクロフロントエンドの統合テストを行う場合、e2eテストツールで行うことができますが、マイクロフロントエンドでない場合と比べると網羅できないテストケースが出てきます。

主なコンテナアプリケーションのフレームワーク

どのような場合に適しているのか

大規模アプリケーション

マイクロフロントエンドのコンセプトやメリットから分かるように、大規模アプリケーション開発時に、多くのチームに分かれ、開発が難しくなった場合、マイクロフロントエンドのアプローチは適しています。
各チームは独自のアーキテクチャを構築でき、独立した開発サイクルでの開発が可能です。

レガシーコードを一部改修する場合

メリットでも書きましたが、レガシーなフレームワークに依存している場合、全面リニューアルは大きなコストがかかります。レガシーコードの一部を改修したい場合、マイクロフロントエンドのアプローチは有用です。