Micro Frontends導入の覚書

電通デジタル エンジニアの おのきです。前回の記事は「SQLスクリプト上でのテーブルや共通テーブル式の依存関係を可視化する」でした。

今回はDentsu Digital Tech Advent Calendar 17 日目の記事になります。

私たちの開発チームでは、社内向け業務システム「EASI」においてデジタル広告のプランニングツールや過去実績のレポーティングツールを日々開発、運用しています。

「EASI」では MicroServices アーキテクチャーを採用し開発を進めており、バックエンドだけでなくフロントエンドについても Micro Frontends という仕組みを取り入れてサービス提供を行っています。

私たちのチームで Micro Frontends を導入してからちょうど一年になるので、ここで改めて導入の目的や選択した技術、導入手順、運用上の注意点や課題と対策をこの記事で覚書としてまとめておきます。ぜひ Micro Frontends 導入の参考にしていただければ幸いです。

導入の経緯と選択技術

まず導入の経緯ですが、もともとは電通デジタル内の広告運用に関わる色々なプロダクト（サービス）群を「EASI」という 1 つのプラットフォームの中で提供したいという思いがありました。

具体的な要件は下記の通りです。

・特定ドメイン配下で、パスを分けて各プロダクトを提供したい
・プロダクトのユーザー認証部分を共通化したい
・Feature Management（例えば、ユーザーごとに使用できる機能管理や機能制限）を適用したい
・各チームで開発されるプロダクトが相互に依存しないようにサービス開発を進めたい

これら要件を満たす技術として、Micro Frontends の導入を決めました。

選択技術については、

Micro Frontends

を参考にしてテストや検討をしました。

最終的には、コンテナ側とプロダクト側との依存が低そうな、
Run-time integration via JavaScript の方式を採用しました。

この方式では、各プロダクトが SPA という型で動作するように作られている前提でそれらを Micro frontends のコンテナ側で読み込み、各プロダクトをパスの変更のみで提供するという動作をします。

※他の技術採用については、コンテナとして iframe を使用する技術や WebComponent を使用する技術があります。
iframe はモバイル対応に対する懸念や利用者の環境とプロダクト毎の UI/UX 面をコンテナ側でも考慮する必要があり、また WebComponent はコンテナ側のメンテナンスが大変になるという懸念があったため、採用を見送りました。

最近発表があった Technology Radar での Micro frontends 技術は Micro frontend anarchy という表記で HOLD となってしまっているのですが、WebComponent(Run-time integration via Web Components)を採用する際の各種 Micro frontends Framework が乱立している状況や、それに伴う SPA の Framework が混在している状況を鑑みてのことだと思っています。

Run-time integration via JavaScript の方式と、開発チームや導入プロダクトを React で統一している、デザインシステムを導入し統制をとってプロダクト開発を進めている状況では Micro frontends を導入しても問題ないと考えています。

導入手順と注意点

導入手順については、micro-frontends-demo をまず参考にしました。今の React の書き方と比較すると古い書き方なのですが、検証には十分でした。

また Hooks に対応したものだと、How to Develop Microfrontends Using React: Step by Step Guide が参考になります。

私たちのチームでの具体的な実装例はここではご紹介できませんが、上記の実装を是非参考にしてください。

また「EASI」において、React で作成されたプロダクトを Micro frontends に組み込んでいく中で発見した注意点をいくつかご紹介します。

1 つ目が、 プロダクト側への react-app-rewired 導入が必要という点です。
Run-time integration via JavaScript についての私たちのコンテナ実装では、compile 後の js が Single chunk でなければならないという制限があります。この点は js ファイルのロードにおいてデメリットと思ってます。

より具体的に説明すると、create-react-app で作成したアプリケーションの package.json 内 start や build エイリアスで使用されている react-scripts は、version2 以降で生成される js が複数ファイルに split されている状態になりました。そのため、 react-app-rewired を利用して 1 つの js ファイルを出力するようにしなければいけないという、 react-scripts の Update に逆行するような対応が必要になり、プロダクト側へも react-app-rewired の利用を強いる事になってしまいます。

現在のところ Micro frontends 化するプロダクトはチーム管理下にあるものが多いため、導入に大きく困ることはないのですが、解決方法がないかは思案中です。

2 つ目が、 CSS の問題です。
これはコンテナに対して CSS の実装（共通スタイルの実装）を含めてしまったという、MicroServices としてはアンチパターンによるものなのですが…コンテナに設置した CSS が全てのプロダクトに影響し、特定の条件でプロダクトのスタイルが大きくずれてしまうという問題がありました。

コンテナの CSS を削除すると既にローンチ済みのプロダクトに影響が出てしまうため、単純にコンテナの CSS を削除する対処はできませんでした。対応方法は少し強引ですが、コンテナの実装を修正し CSS に問題が発生するプロダクトを読み込む際は、特別に共通 CSS を無効にしてプロダクト側の CSS に置き換えるという対応をしています…

急ぎ作成対応したものが後々影響及ぼすというよくある事例ではありますが、きちんと MicroServices 化を進めていく（コンテナとプロダクトの責務を切り分ける）ことで解消されてくる部分かなと思ってます。
プロダクト側で外部 CSS を利用するケースなど他にも対応を必要とするケースがでてくることは想定されますが、日々試行錯誤といったところです。

おわりに

開発チームでは内製でのフロントエンド開発はまだまだスタートしたばかりですが、今回紹介した Micro frontends に限らず、React などフロントエンドに関する技術、デザインシステムに関し日々研鑽を積んでいます。
電通デジタルではフロントエンドエンジニアを絶賛募集中ですので、是非興味あればご応募ください。

今回紹介した記事が読んだ方の参考になれば幸いです。

18 日目は「grpc-gatewayでinterceptorとヘルスチェックエンドポイントを実装する」です。次回もよろしくお願いいたします。