Micro Frontendsで築いた共通基盤と運用の試行錯誤 / Building a Shared Platform with Micro Frontends: Operational Learnings

Slide 1

Slide 1 text

Micro Frontendsで築いた共通基盤と運用の試行錯誤 Building a Shared Platform with Micro Frontends: Operational Learnings 金子優斗 (@kyntk_1128) Yuto Kaneko

Slide 2

Slide 2 text

Survey 󰢧 ● ｢マイクロフロントエンド｣って聞いたことあるかた?   Have you heard of “Micro Frontends” before?    ● マイクロフロントエンドを採用したことがあるかた?  Have you ever used Micro Frontends? 

Slide 3

Slide 3 text

→ Solution: Micro Frontends (MFE)  巨大化したフロントエンドをどう分割するか How do we break down a growing frontend? 出典: Micro Frontends - extending the microservice idea to frontend development

Slide 4

Slide 4 text

金子優斗 (@kyntk_1128) Yuto Kaneko ● 2024/05 Money Forward Join ● Nagoya Branch ● Running 󰝊 ● Coffee ☕ ● 最近の目標 / My recent goal ｢懸垂ができるようになりたい｣ I want to be able to do pull-ups.

Slide 5

Slide 5 text

Agenda ❏ マネーフォワードクラウドについて   ❏ マイクロフロントエンドとは   ❏ 導入の目的   ❏ MFE のデリバリー方法   ❏ 運用で見えてきた課題と学び   ❏ 未解決の課題と今後   ❏ About Money Forward Cloud  ❏ What Micro Frontends Are  ❏ Why We Adopted Micro Frontends  ❏ How We Deliver Micro Frontends  ❏ Challenges and Learnings  ❏ Unresolved Challenges and What’s Next 

Slide 6

Slide 6 text

Slide 7

Slide 7 text

マネーフォワードクラウドとは出典元 : 株式会社マネーフォワード会社紹介資料法人向けバックオフィス向け　 SaaS ファイナンスサービス個人向け金融機関等向け PFM（家計簿・資産管理）サービス Fintech推進・DX支援金融機関・特定サービス向けマネーフォワードデジタル通帳・かんたん通帳 Money Forward Cloud is a SaaS for businesses

Slide 8

Slide 8 text

マネーフォワードクラウドの共通基盤を開発 Developing the shared platform for Money Forward Cloud 等  通知基盤 / Notiﬁcation Platform 契約基盤 / Contract Platform 認証基盤 / Authentication Platform 承認ワークフロー基盤 / Approval Workﬂow Platform

Slide 9

Slide 9 text

申請内容入力  Enter application details  申請、承認のステップ Enter application details 申請内容･承認者確認、提出   Review details and approvers, then submit  承認  Approval 

Slide 10

Slide 10 text

Slide 11

Slide 11 text

巨大化したフロントエンドをどう分割するか How can we split a growing / monolithic frontend? 出典: Micro Frontends - extending the microservice idea to frontend development

Slide 12

Slide 12 text

MFE：マイクロサービスの思想をフロントエンドに拡張 Extending the microservices mindset to the frontend 出典: Micro Frontends - extending the microservice idea to frontend development A B C TeamA 󰞵󰞵󰞵󰞵󰞵 TeamB 󰠁󰠁󰠁 TeamC 󰳕󰳕󰳕󰳕 複数のチームで開発し、統合 

Slide 13

Slide 13 text

❏ About Money Forward Cloud  ❏ What Micro Frontends Are  ❏ Why We Adopted Micro Frontends  ❏ How We Deliver Micro Frontends  ❏ Challenges and Learnings  ❏ Unresolved Challenges and What’s Next  Agenda ❏ マネーフォワードクラウドについて   ❏ マイクロフロントエンドとは   ❏ 導入の目的   ❏ MFE のデリバリー方法   ❏ 運用で見えてきた課題と学び   ❏ 未解決の課題と今後  

Slide 14

Slide 14 text

自社が抱えていた問題：似た機能が個別実装されていた Our internal issue: similar features were implemented separately across products Product A  ⚙ 承認ワークフロー A Product B  ⚙ 承認ワークフロー B TeamA 󰞵󰞵󰞵󰞵󰞵 TeamB 󰠁󰠁󰠁 データの二重管理、UI/UXの不統一などの問題  Duplicated data management and inconsistent UI/UX 

Slide 15

Slide 15 text

● プロダクト側での開発・保守の負荷を大幅に軽減  Big reduction in product-side workload  ● 切り出されたチームが自律的に改善  Dedicated team improves autonomously  マイクロサービスとして切り出し、UI も含めて提供 Extracted as a microservice and provided with its UI as well Team MFE 󰳕󰳕󰳕 ⚙ 承認ワークフロー基盤 ⚙ 承認ワークフロー基盤 ⚙ 承認ワークフロー基盤 Product A  Product B 

Slide 16

Slide 16 text

なぜ UI も提供するのか / Why provide the UI, too? 1. 承認ワークフローの UI は非常に複雑なため / UI is complex  2. 全プロダクトで同じ UI を使い、一貫したUXを実現するため / Consistent UX across products  3. 価値を届けるスピードを上げるため / Faster delivery of value 

Slide 17

Slide 17 text

複数チームが独立して開発・運用しながら共通機能や UI を共有したい  Independent teams need to share features/UI  どのようなときにMFEを導入するか / When to use MFE UIが複雑で、各プロダクトが個別に実装する負荷が高い (※後で補足)  UI is complex and costly to build per product      A B C TeamA 󰞵󰞵󰞵󰞵󰞵 TeamB 󰠁󰠁󰠁 TeamC 󰳕󰳕󰳕󰳕 ⚙ 承認ワークフロー A ⚙ 承認ワークフロー B 󰷺 󰷺

Slide 18

Slide 18 text

Slide 19

Slide 19 text

垂直統合 / Vertical Composition  垂直統合 vs 水平統合水平統合 / Horizontal Composition  Team A Team B https://xxx/feat-a https://xxx/feat-b Team A Team A https://xxx/feat-a https://xxx/feat-b Team C Team B Team C Team B

Slide 20

Slide 20 text

ビルドタイム統合/Build-time Composition  ランタイム統合/Runtime Composition  ⚙ 承認ワークフロー基盤 Host Product ⚙ 承認ワークフロー基盤 Host Product 👍即時展開 & 👎障害対応責任  Instant rollout & Owns failure handling  ビルドタイム統合 vs ランタイム統合

Slide 21

Slide 21 text

Shadow Dom Web Componentsを利用 ● Shadow DOM によるスタイルの独立性  Style isolation with Shadow DOM  ● フレームワークに依存しない柔軟性  Framework-agnostic ﬂexibility 

Slide 22

Slide 22 text

● マイクロフロントエンド (MFE) とは  ○ マイクロサービスの考え方をフロントエンドにも拡張し、   各チームが独立して機能を開発・提供できるようにするアーキテクチャ   ● なぜMFEを選択したか  ○ プロダクト側での開発負荷を大幅に軽減するため   ○ 小さいチームで自律的に高速に価値を届けるため   ○ 1ページ内でシームレスな体験を実現するため   ○ プロダクトをまたいで一貫した UXを実現するため  ● MFE のデリバリー方法  ○ 水平統合  ○ ランタイム統合  ○ Web Components  ここまでのまとめ / Summary

Slide 23

Slide 23 text

Slide 24

Slide 24 text

✅ プロダクト側での開発負荷を大幅に軽減する  Big reduction in product workload  ✅ 小さいチームで自律的に高速に価値を届ける  Small teams ship value fast  ✅ 1ページ内でシームレスな体験を実現する  Seamless in-page experience  ✅ プロダクトをまたいで一貫したUXを実現する  Seamless in-page experience  当初の目的はすべて達成 / We achieved all initial goals

Slide 25

Slide 25 text

⚠ 拡張性と組み込みコストのトレードオフ  Trade-oﬀ: ﬂexibility vs integration cost  ⚠ 疎結合設計とその限界  Limits of loose coupling  ⚠ 認証・認可のアーキテクチャの課題と、変更  Auth architecture issues & changes  ⚠ UIの一貫性  Consistent UI within the same page  見えてきた課題 / Challenges uncovered

Slide 26

Slide 26 text

コンポーネントをホストプロダクト側で拡張をしたい要望   Requests to extend components on the host side  課題1. UI をどこまで共通化すべきか / How far should UI be shared? あるステップに設定追加したい独自の条件で承認者を選びたいカラムを追加したいラベルを変えたい承認前にコールバックを挟みたい

Slide 27

Slide 27 text

MFEが適している範囲 Where MFE is suitable 拡張の必要性が低く、実装難易度が高いもの Low need for extension, high implementation cost プロダクト独自の拡張性 Product-speciﬁc extensibility 実装難易度 Implementation difﬁculty プロダクト独自の拡張が増えると保守が大変実装難易度が低いものは提供価値が高くない

Slide 28

Slide 28 text

Slide 29

Slide 29 text

疎結合設計: Custom Eventを用いた伝達 Loose coupling: communication via Custom Events Host product MFE component MFE component Props 1 2

Slide 30

Slide 30 text

不採用の案: Callbackを用いたコミュニケーション Rejected approach: communication via callbacks Host product MFE component MFE component Callback Call Callback Call Callback関数を渡す方式だと、  拡張時にホスト側の修正が必要になる  Callbacks require host changes whenever extensions are needed 

Slide 31

Slide 31 text

Event Bus Pattern EventをPublish, Subscribe  することで、  お互いを知らずに情報をやりとり  MFE component MFE component Event Bus By publishing / subscribing events, they can exchange data without knowing each other 

Slide 32

Slide 32 text

CustomEvent設計の課題 1: 描画タイミングの問題 Send State MFE component MFE component Route Component Submit Button Component ❌ 描画タイミングによっては、  Stateの同期に失敗する  Depending on render timing, state sync can fail 

Slide 33

Slide 33 text

CustomEvent設計の課題 1: 描画タイミングの問題 Stateの再送レンダリング完了通知レンダリング完了のイベントを送信  Stateを再送するようにした  Send a “rendered” event and resend state after that  MFE component MFE component 描画タイミングによっては、  Stateの同期に失敗する  Depending on render timing, state sync can fail 

Slide 34

Slide 34 text

コールバック関数も受け取れるように  Added support for callbacks  CustomEvent設計の課題 2: イベント駆動の限界特定のイベント前に、  同期的に処理を挟む必要が出てきた  Needed synchronous processing before certain events  承認前にバリデーションを挟みたい

Slide 35

Slide 35 text

Slide 36

Slide 36 text

ログインはホストプロダクトでのみ行う / Login happens only on the host product  ユーザーはログイン状態で MFEを利用する / Users access the MFE while already logged in  課題3. 認証・認可のアーキテクチャの課題と、変更 Auth architecture issues & changes

Slide 37

Slide 37 text

認証・認可のアーキテクチャv1 Auth architecture v1 Host product Frontend MFE Frontend Host product Backend MFE Backend Rendering API Request (Same Origin) Auth Authenticated request (with permissions) MFE Frontend からのリクエストはSame Origin扱い  MFE Backend は認証済みのリクエストのみを扱える 

Slide 38

Slide 38 text

認証・認可のアーキテクチャv1の課題 Auth Architecture v1: Issues Host product Frontend MFE Frontend Host product Backend MFE Backend Auth 1. Host Backendのスレッド占有による、レイテンシ悪化  2. API拡張の際 Host の更新に依存にする拡張性の制限  MFE Backendの処理待ちスレッド Host Backend による拡張制限 Host BE thread blocking → higher latency API extensions depend on host updates → limited ﬂexibility

Slide 39

Slide 39 text

要件に合わせて適切なアーキテクチャを設計する必要がある  Architecture must ﬁt the requirements  認証・認可のアーキテクチャv2 Auth architecture v2 Host product Frontend MFE Frontend Host product Backend Rendering API Request (Cross Origin) MFE Backend Auth request Response with permissions

Slide 40

Slide 40 text

見えてきた課題 / Challenges uncovered ⚠ 拡張性と組み込みコストのトレードオフ  Trade-oﬀ: ﬂexibility vs integration cost  ⚠ 疎結合設計とその限界  Limits of loose coupling  ⚠ 認証・認可のアーキテクチャの課題と、変更  Auth architecture issues & changes  ⚠ UIの一貫性  Consistent UI within the same page 

Slide 41

Slide 41 text

UI をアップデートするのは各チーム依存のため  ホストプロダクトと MFE の UI の不一致が発生  Diﬀerent team update timings cause UI mismatches between the host and the MFE on the same page.  課題4. UIの一貫性 / Consistent UI within the same page MFE Team 󰳕󰳕󰳕 Button Product Team 󰳕󰳕󰳕 Button Design system v1 Design system v2 🚀 🚀

Slide 42

Slide 42 text

コンポーネントライブラリの活用推進 Promoting use of the component library MFE Team 󰳕󰳕󰳕 Product Team 󰳕󰳕󰳕 Button Design system v2 Component Library Team 󰳕󰳕󰳕 Build-time Composition Build-time Composition 🚀 🚀 コンポーネントライブラリを使うことで最新のデザインシステムに追従   Using the component library keeps us aligned with the latest design system 

Slide 43

Slide 43 text

Slide 44

Slide 44 text

書類提出までのステップで新たにDialog が追加された  A new dialog was added in the submission ﬂow  ● プロダクトに組み込んでのE2Eが必要  E2E must run on each host product  ● プロダクトの変更によりE2Eがテストが落ちることもあり、修正が大変  Host changes often break E2E, making ﬁxes costly  未解決の課題1: E2E テストのメンテナンスの課題 Unresolved Issue 1: E2E test maintenance

Slide 45

Slide 45 text

未解決の課題2: アセットサイズの問題 Unresolved Issue 2: Asset size growth ● Web Componentsはホスト、MFEで異なるライブラリを使える  Host and MFE can use diﬀerent libraries  ● ブラウザにダウンロードするアセットサイズが大きくなる  Larger asset downloads  ● 十分にパフォーマンスの監視もできていない  Performance monitoring is still limited  v19.2.0 v18.3.1

Slide 46

Slide 46 text

● 対応がプロダクトごとに異なり、MFEと連携ができていない  Diﬀerent i18n approaches per product, not aligned with MFE  ● 仕組みの標準化に取り組んでいる  Working on standardising the approach  未解決の課題3: i18n の不統一 Unresolved Issue 3: Inconsistent i18n English 日本語

Slide 47

Slide 47 text

● 共通ライブラリの提供  Providing shared libraries  ● 実装ガイドラインの策定  Creating implementation guidelines  MFEを実装するための仕組みを整えて、活用を促進  Improving the foundation to make MFE easier to adopt  今取り組んでいること: MFE の標準化 Current Focus: Standardizing MFE

Slide 48

Slide 48 text

できたこと  ✅ プロダクト側での開発負荷軽減  ✅ 小さいチームで自律的に価値提供  ✅ 1ページ内でシームレスな体験を実現  ✅ 一貫したUXを実現  まとめ学び  🧠 UI の共通化範囲の判断  🧠 CustomEvent設計の工夫  🧠 認証アーキテクチャの変更  🧠 UIの一貫性    今後  ▶ E2E テスト、アセットサイズ、i18n  ▶ MFEの標準化 

Slide 49

Slide 49 text

No content