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

Slide 1

Slide 1 text

マイクロフロントエンドの現状確認 2022.09.27 Yuki Kodama / @kuy UB Tech vol.3

Slide 2

Slide 2 text

マイクロフロントエンドはどこから来たのか？実装パターン現状確認 01 02 03 2

Slide 3

Slide 3 text

01 | マイクロフロントエンドはどこから来たのか？

Slide 4

Slide 4 text

4 マイクロフロントエンド https://micro-frontends.org/

Slide 5

Slide 5 text

5 初出　ThoughtWorks Technology Radar https://www.thoughtworks.com/radar/techniques/micro-frontends

Slide 6

Slide 6 text

6 背景　なぜマイクロフロントエンドなのか 1. フロントエンドヘビーなアプリケーションの増加 2. マイクロサービスアーキテクチャの浸透

Slide 7

Slide 7 text

7 古典的なモノリス　アーキテクチャの変遷モノリスアプリケーションフロントエンド + バックエンド

Slide 8

Slide 8 text

8 フロントエンドの分離　アーキテクチャの変遷フロントエンドバックエンド

Slide 9

Slide 9 text

9 マイクロサービス化　アーキテクチャの変遷フロントエンドマイクロサービスマイクロサービスマイクロサービス BFF BFF BFF

Slide 10

Slide 10 text

10 復習: マイクロサービスのメリット ● 独立した小さなデプロイ単位 ○ デプロイ頻度の向上 ● 技術選択の自由度の高さ ○ 陳腐化したとき捨てやすい ● 自律的な開発組織・チーム ○ 高凝集・疎結合 ● サービス全体のレジリエンス向上

Slide 11

Slide 11 text

11 フロントエンドモノリス　アーキテクチャの変遷フロントエンドモノリスマイクロサービスマイクロサービスマイクロサービス BFF BFF BFF

Slide 12

Slide 12 text

12 フロントエンドモノリスの課題 ● 独立した小さなデプロイ単位 → ❌ ○ デプロイ頻度の向上 ● 技術選択の自由度の高さ → ❌ ○ 陳腐化したとき捨てやすい → ❌ ● 自律的な開発組織・チーム ○ 高凝集・疎結合 → ❌ ● サービス全体のレジリエンス向上 → ❌ マイクロサービスで得られてた恩恵が消える

Slide 13

Slide 13 text

13 補足: フロントエンドモノリスの課題 ● フロントエンドは分離しにくい ○ 統一された見た目と体験の提供 ○ ページ内の異なる関心事 ● フロントエンドは膨らみがち ○ APIは使い回せても画面は使い回せない ○ コンポーネントの再利用とは別の話

Slide 14

Slide 14 text

14 マイクロフロントエンド化　アーキテクチャの変遷マイクロサービスマイクロサービスマイクロサービス BFF BFF BFF マイクロフロントエンドマイクロフロントエンドマイクロフロントエンドマイクロフロントエンドで課題の解決を図る

Slide 15

Slide 15 text

"An architectural style where independently deliverable frontend applications are composed into a greater whole" 15 Cam Jackson / martinfowler.com

Slide 16

Slide 16 text

"独立してデプロイ可能なフロントエンドアプリケーションをより大きな全体として構成できるアーキテクチャスタイル" 16 Cam Jackson / martinfowler.com

Slide 17

Slide 17 text

02 | 実装パターン

Slide 18

Slide 18 text

18 実装パターン 1. ページ毎のフロントエンド分離 2. 実行時の統合おすすめできない実装パターン 1. ビルド時の統合 2. サーバー側テンプレート方式

Slide 19

Slide 19 text

19 ページ毎のフロントエンド分離　実装パターン /products/123 モノリスアプリケーションフロントエンド /users/123 /home /about

Slide 20

Slide 20 text

20 実行時の統合　実装パターン 1. iframeを使った統合 2. JavaScriptを使った統合 3. Web Componentsを使った統合

Slide 21

Slide 21 text

21 iframeを使った統合　実装パターン iframe ホスト ● メリット ○ 枯れた技術スタックで実現可能 ● デメリット ○ ホスト側アプリケーションの変更が必要になるケースもある ○ 高さを調整する必要がある ○ リンクのクリックなど、iframe内で発生したイベントを拾う必要がある ○ エラー発生時のハンドリングが煩雑ホスト側に用意したiframe内にマイクロフロントエンド側のアプリケーションを展開する。

Slide 22

Slide 22 text

22 JavaScriptを使った統合　実装パターン ● メリット ○ iframeのような明らかなデメリットがない ● デメリット ○ CSSの特性上、想定外のスタイルが適用されてデザインが壊れる可能性がある ○ ページ全体で読み込むJavaScriptファイルのサイズが大きくなるホスト側にマイクロフロントエンド側の JavaScriptを読み込み、直接展開する。 Micro frontend ホスト

Slide 23

Slide 23 text

23 Web Componentsを使った統合　実装パターン ● メリット ○ マイクロフロントエンドの提供方法が独自にならず、Web標準で実現できる ● デメリット ○ （見当たらないが、強いて言えば使っている人が多くないので情報が少ない）マイクロフロントエンド側はWeb Componentsを提供し、ホスト側は読み込んで使う。 Web Components ホスト

Slide 24

Slide 24 text

03 | 現状確認

Slide 25

Slide 25 text

25 現状確認　導入ハードルの低下 Web Components 2022年6月15日、Microsoft Internet Explorer 11のサポート終了に伴い、マイクロフロントエンドを実現する要素技術としてのWeb Components採用が現実的な選択肢となった。 https://developer.mozilla.org/en-US/docs/Web/Web_Components Web Componentsが他の代替技術に対してどのくらいアドバンテージがあるのかについては事例紹介にて。

Slide 26

Slide 26 text

26 現状確認　アーキテクチャの見直しプロダクトの成長に応じたアーキテクチャ選択アーキテクチャには「正しいもの」はなくて、フェーズや状況に応じた「適切なもの」があるだけ。プロダクトは生き物なので、新規開発を止めて一気に刷新するのは危険が伴うし、アーキテクチャの刷新が完璧な形で行われるのも稀。アーキテクチャ刷新の現実的なプロセスは？

Slide 27

Slide 27 text

27 現状確認　アーキテクチャの見直しモノリスアプリケーションフロントエンド + バックエンドモノリスからモジュラモノリスへモノリスアプリケーションモジュールモジュール

Slide 28

Slide 28 text

28 現状確認　アーキテクチャの見直しモノリスアプリケーションフロントエンド + バックエンドモノリスアプリケーションフロントエンドモノリスを残しつつ、部分的にフロントエンド分離

Slide 29

Slide 29 text

29 現状確認　アーキテクチャの見直しモノリスアプリケーションフロントエンドモノリスを残しつつ、マイクロサービス導入モノリスアプリケーションフロントエンドマイクロサービスマイクロサービス BFF BFF

Slide 30

Slide 30 text

30 現状確認　アーキテクチャの見直し複雑さを低減していく努力は続ける前提で、新しいアーキテクチャを小さく試すことはできる。モノリスアプリケーションモノリスフロントエンドマイクロサービスマイクロサービス BFF BFF マイクロサービス BFF マイクロフロントエンド

Slide 31

Slide 31 text

31 まとめ ● マイクロフロントエンドはマイクロサービスと密接な関係がある ● Web Componentsを利用しやすい環境が整ってきた ● アーキテクチャ刷新を小さく始める ○ モジュラモノリス ○ ページ毎のフロントエンド分割 31

Slide 32

Slide 32 text

32 Thank you for listening.