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

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

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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

17. 02 |
    実装パターン
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

24. 03 |
    現状確認
    

    View Slide

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が他の代替技術に対してどのくらいアドバンテージがあるのかについては事例紹介にて。
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

32. 32
    Thank you for listening.
    

    View Slide