マイクロフロントエンドの現状確認

マイクロフロントエンドという技術用語はThoughtWorks 社によって2016年に提唱されました。2014年に同社が提唱したマイクロサービスはすでにアーキテクチャの選択肢として浸透しつつある一方で、マイクロサービスは馴染みが薄く、実際にプロダクトに取り入れた実例を聞く機会もあまりない、という方も少なくないと思います。

マイクロフロントエンドの基本的なアイデアから、導入のモチベーション、いくつかの現実的な実装パターンを知っていただくことで、マイクロフロントエンドがより良いアーキテクチャを実現するための選択肢のひとつになるきっかけになればと思います。

Transcript

1. マイクロフロントエンドの現状確認 2022.09.27 Yuki Kodama / @kuy UB Tech vol.3
2. マイクロフロントエンドはどこから来たのか？ 実装パターン 現状確認 01 02 03 2
3. 01 | マイクロフロントエンドはどこ から来たのか？
4. 4 マイクロフロントエンド https://micro-frontends.org/
5. 5 初出　ThoughtWorks Technology Radar https://www.thoughtworks.com/radar/techniques/micro-frontends
6. 6 背景　なぜマイクロフロントエンドなのか 1. フロントエンドヘビーなアプリケーションの増加 2. マイクロサービスアーキテクチャの浸透
7. 7 古典的なモノリス　アーキテクチャの変遷 モノリスアプリケーション フロントエンド + バックエンド
8. 8 フロントエンドの分離　アーキテクチャの変遷 フロントエンド バックエンド
9. 9 マイクロサービス化　アーキテクチャの変遷 フロントエンド マイクロ サービス マイクロ サービス マイクロ サービス BFF BFF BFF
10. 10 復習: マイクロサービスのメリット • 独立した小さなデプロイ単位 ◦ デプロイ頻度の向上 • 技術選択の自由度の高さ ◦ 陳腐化したとき捨てやすい • 自律的な開発組織・チーム ◦ 高凝集・疎結合 • サービス全体のレジリエンス向上
11. 11 フロントエンドモノリス　アーキテクチャの変遷 フロントエンドモノリス マイクロ サービス マイクロ サービス マイクロ サービス BFF BFF BFF
12. 12 フロントエンドモノリスの課題 • 独立した小さなデプロイ単位 → ❌ ◦ デプロイ頻度の向上 • 技術選択の自由度の高さ → ❌ ◦ 陳腐化したとき捨てやすい → ❌ • 自律的な開発組織・チーム ◦ 高凝集・疎結合 → ❌ • サービス全体のレジリエンス向上 → ❌ マイクロサービスで得られてた恩恵が消える
13. 13 補足: フロントエンドモノリスの課題 • フロントエンドは分離しにくい ◦ 統一された見た目と体験の提供 ◦ ページ内の異なる関心事 • フロントエンドは膨らみがち ◦ APIは使い回せても画面は使い回せない ◦ コンポーネントの再利用とは別の話
14. 14 マイクロフロントエンド化　アーキテクチャの変遷 マイクロ サービス マイクロ サービス マイクロ サービス BFF BFF BFF マイクロ フロントエンド マイクロ フロントエンド マイクロ フロントエンド マイクロフロントエンドで課題の解決を図る
15. "An architectural style where independently deliverable frontend applications are composed into a greater whole" 15 Cam Jackson / martinfowler.com
16. "独立してデプロイ可能なフロントエンドア プリケーションをより大きな全体として構 成できるアーキテクチャスタイル" 16 Cam Jackson / martinfowler.com
17. 02 | 実装パターン
18. 18 実装パターン 1. ページ毎のフロントエンド分離 2. 実行時の統合 おすすめできない実装パターン 1. ビルド時の統合 2. サーバー側テンプレート方式
19. 19 ページ毎のフロントエンド分離　実装パターン /products/123 モノリスアプリケーション フロント エンド /users/123 /home /about
20. 20 実行時の統合　実装パターン 1. iframeを使った統合 2. JavaScriptを使った統合 3. Web Componentsを使った統合
21. 21 iframeを使った統合　実装パターン iframe ホスト • メリット ◦ 枯れた技術スタックで実現可能 • デメリット ◦ ホスト側アプリケーションの変更が必要にな るケースもある ◦ 高さを調整する必要がある ◦ リンクのクリックなど、iframe内で発生した イベントを拾う必要がある ◦ エラー発生時のハンドリングが煩雑 ホスト側に用意したiframe内にマイクロフロント エンド側のアプリケーションを展開する。
22. 22 JavaScriptを使った統合　実装パターン • メリット ◦ iframeのような明らかなデメリットがない • デメリット ◦ CSSの特性上、想定外のスタイルが適用され てデザインが壊れる可能性がある ◦ ページ全体で読み込むJavaScriptファイルの サイズが大きくなる ホスト側にマイクロフロントエンド側の JavaScriptを読み込み、直接展開する。 Micro frontend ホスト <script src=”...” />
23. 23 Web Componentsを使った統合　実装パターン • メリット ◦ マイクロフロントエンドの提供方法が独自に ならず、Web標準で実現できる • デメリット ◦ （見当たらないが、強いて言えば使っている 人が多くないので情報が少ない） マイクロフロントエンド側はWeb Componentsを 提供し、ホスト側は読み込んで使う。 Web Components ホスト <script src=”...” />
24. 03 | 現状確認
25. 25 現状確認　導入ハードルの低下 Web Components 2022年6月15日、Microsoft Internet Explorer 11のサポート終了に伴い、マイクロフロントエンドを実 現する要素技術としてのWeb Components採用が現実的な選択肢となった。 https://developer.mozilla.org/en-US/docs/Web/Web_Components Web Componentsが他の代替技術に対してどのくらいアドバンテージがあるのかについては事例紹介にて。
26. 26 現状確認　アーキテクチャの見直し プロダクトの成長に応じたアーキテクチャ選択 アーキテクチャには「正しいもの」はなくて、フェーズや状況に応じた「適切なもの」があるだけ。 プロダクトは生き物なので、新規開発を止めて一気に刷新するのは危険が伴うし、アーキテクチャの 刷新が完璧な形で行われるのも稀。 アーキテクチャ刷新の現実的なプロセスは？
27. 27 現状確認　アーキテクチャの見直し モノリスアプリケーション フロントエンド + バックエンド モノリスからモジュラモノリスへ モノリスアプリケーション モジュール モジュール
28. 28 現状確認　アーキテクチャの見直し モノリスアプリケーション フロントエンド + バックエンド モノリスアプリケーション フロントエンド モノリスを残しつつ、部分的にフロントエンド分離
29. 29 現状確認　アーキテクチャの見直し モノリスアプリケーション フロントエンド モノリスを残しつつ、マイクロサービス導入 モノリスアプリケーション フロントエンド マイクロ サービス マイクロ サービス BFF BFF
30. 30 現状確認　アーキテクチャの見直し 複雑さを低減していく努力は続ける前提で、 新しいアーキテクチャを小さく試すことはできる。 モノリスアプリケーション モノリスフロントエンド マイクロ サービス マイクロ サービス BFF BFF マイクロ サービス BFF マイクロ フロント エンド
31. 31 まとめ • マイクロフロントエンドはマイクロサービスと密接な関係がある • Web Componentsを利用しやすい環境が整ってきた • アーキテクチャ刷新を小さく始める ◦ モジュラモノリス ◦ ページ毎のフロントエンド分割 31
32. 32 Thank you for listening.