「Fintech SaaSにおける品質を高めるためのフロントエンド開発論」での発表で利用したスライドです。
基盤システムへのマイクロフロントエンドの活用事例2023/03/30@sainu(株式会社マネーフォワード)
View Slide
自己紹介
自己紹介● sainu / 道祖克理(さいのうかつとし)● Ruby, TypeScript● マネーフォワードでは基盤プロダクトを開発● 2022/09〜 岐阜市に移住冷やしたぬきそば / 更科 みそベトコンラーメン / 香楽 カプサイメン / カプサイメン岐阜タンメンも良いが...
このスライドについて全てを話すには時間が足りないので、薄く広くなってしまいました 🙏消化不良の方はこちら👇マイクロサービスのその先へ。マネーフォワードのビジネスを加速するマイクロフロントエンドという選択ただ、記事に書けてないことも話します 🤭
目次● 解決したい課題● マイクロフロントエンドとは● どのように実践したか● 課題● 所感
解決したい課題
解決したい課題● マネーフォワードクラウドのサービス数が毎年増え続ける 📈
解決したい課題● マネーフォワードクラウドのサービス数が毎年増え続けた 📈● これらサービスの基盤となる機能がサービスに個別最適化されリリース🚢
解決したい課題● マネーフォワードクラウドのサービス数が毎年増え続ける 📈● これらサービスの基盤となる機能がサービスに個別最適化されリリース🚢● 各サービスで似たような機能がリリースされても複数サービスを併用するユーザーは少なかった
解決したい課題● マネーフォワードクラウドのサービス数が毎年増え続ける 📈● これらサービスの基盤となる機能がサービスに個別最適化されリリース🚢● 各サービスで似たような機能がリリースされても複数サービスを併用するユーザーは少なかった● が...事業が成長しサービスを併用するするユーザーが増えて課題が顕著に○ サービス間でデータが同期されておらず、持っているデータ構造が違うために、 ユーザーが複数のサービスでデータを同期する手間が繰り返し発生 😇
解決したい課題● マネーフォワードクラウドのサービス数が毎年増え続ける 📈● これらサービスの基盤となる機能がサービスに個別最適化されリリース🚢● 各サービスで似たような機能がリリースされても複数サービスを併用するユーザーは少なかった● が...事業が成長しサービスを併用するするユーザーが増えて課題が顕著に○ サービス間でデータが同期されておらず、持っているデータ構造が違うために、 ユーザーが複数のサービスでデータを同期する手間が繰り返し発生 😇● いくつもの開発チームが同じ機能を繰り返し開発するコストが発生。UI/UX、品質がバラバラ
解決したい課題● マネーフォワードクラウドのサービス数が毎年増え続ける 📈● これらサービスの基盤となる機能がサービスに個別最適化されリリース🚢● 各サービスで似たような機能がリリースされても複数サービスを併用するユーザーは少なかった● が...事業が成長しサービスを併用するするユーザーが増えて課題が顕著に○ サービス間でデータが同期されておらず、持っているデータ構造が違うために、 ユーザーが複数のサービスでデータを同期する手間が繰り返し発生 😇● いくつもの開発チームが同じ機能を繰り返し開発するコストが発生。UI/UX、品質がバラバラ● 今後も新規サービスに同様の開発が発生することが想定
解決したい課題● マネーフォワードクラウドのサービス数が毎年増え続ける 📈● これらサービスの基盤となる機能がサービスに個別最適化されリリース🚢● 各サービスで似たような機能がリリースされても複数サービスを併用するユーザーは少なかった● が...事業が成長しサービスを併用するするユーザーが増えて課題が顕著に○ サービス間でデータが同期されておらず、持っているデータ構造が違うために、 ユーザーが複数のサービスでデータを同期する手間が繰り返し発生 😇● いくつもの開発チームが同じ機能を繰り返し開発するコストが発生。UI/UX、品質がバラバラ● 今後も新規サービスに同様の開発が発生することが想定なんとかせにゃいかん!!
マイクロフロントエンドとは
マイクロフロントエンド複数の小さなフロントエンドアプリケーションを組み合わせて大きなアプリケーションを構築するアーキテクチャパターン
マイクロフロントエンドの利点1.開発速度向上開発・デプロイが独立したことで開発速度が向上2.技術異質性サービスに適した言語で開発が可能に3.障害の局所化障害時に影響範囲が限定的に4.変更容易性バグ修正や機能追加が容易に5.再利用性サービスが他のプロジェクトで再利用できる 出典: micro-frontends.org
マイクロフロントエンドの統合パターンビルドタイム ランタイムアプローチ コンテナアプリのビルド時にマイクロフロントエンドをインストールする独立して配置されたマイクロフロントエンドを動的にロードするパフォーマンス ⚠(重複リソースをバンドルしないように注意)❌セキュリティ ✅ ⚠(適切なセキュリティポリシーやCORS設定を適用する)技術スタックの柔軟さ ❌ ✅デプロイ ❌ ✅高いスケーラビリティ依存管理の複雑さ ✅ ⚠(マイクロフロントエンド間の互換性を保つためのガバナンスやコミュニケーションが必要)ユーザーに一つのアプリケーションとして見せるために ...
マイクロフロントエンドの分割パターン1.水平分割画面内の要素で分割、 1つの画面上に複数のフロントエンドアプリケーションが同居例 Spotify、マクアケ2.垂直分割ルーティング単位で分割、 1画面に1アプリケーション例 CircleCI、日経電子版出典: マイクロフロントエンド
思うに...
「こうあるべき」という形は無い
「こうあるべき」という形は無い0か100かでもない
型にハメる必要はないコンテナアプリ水平分割なら...構成要素は全てマイクロフロントエンドになっているのが理想!そんなことは無いマイクロフロントエンドマイクロフロントエンドマイクロフロントエンドマイクロフロントエンド
型にハメる必要はないページ 垂直分割なら...全てのページがマイクロフロントエンドとして分離されているのが理想!そんなことは無いページページページページページページマイクロフロントエンド
サービス特性や規模、抱えている課題、開発組織の文化や状況置かれている状況によって解は違う
今自分が置かれている状況でどうあるべきかを柔軟に考えるのが大事
どのように実践したか
分割、統合分割● 特定URLのコンテンツ(垂直)● あるボタン(水平)● 画面の一部のUI(水平)水平or垂直はあまり意識せず、どの機能をどういう形で提供すべきか?で考えた統合方法● ビルドタイム? ランタイム? 👉 ランタイム○ デプロイの独立性を優先● iframe? JS? web components? FW? SSI? 👉 web components○ Web標準API○ 属性値の変更検知やライフサイクルをサポート● クライアント? サーバー? エッジ? 👉 クライアント○ SSOの要件なし○ CSRやSSR様々なアプリがある
どう実装したか● アプリケーションはReactで開発● Reactアプリをカスタム要素として登録するJSを配信● コンテナアプリはHTMLにカスタム要素を記述しJSを読み込むことでランタイム統合を実現● 後方互換性のない変更に備えてJSのURLにバージョンを含める(https://path/to/v1/xxx.js )● サービスのバックエンドをAPI Gateway兼認証サーバーとしてリクエストを認証● マイクロフロントエンド間のデータ共有○ URLのクエリ○ CustomEventで変更通知詳しくはzennの記事に書いてます👉マイクロサービスのその先へ。マネーフォワードのビジネスを加速するマイクロフロントエンドという選択
意識したこと● なるべく特定フレームワークに依存せずにWeb標準APIで作ること。● 統合されるサービス数が多く、使われている技術も多種多様。● サービスチームに統合のために新たなツールの導入をさせない。
課題
課題● フロントエンドとバックエンドを統合テストするために統合レイヤーとなるサービスをセットアップする必要がある。○ マイクロフロントエンド単体でエンドツーエンドの開発ができる状態が理想...
所感
所感1. 特定領域の開発をUIからインフラまで専門チームに移譲することには成功した2. たくさんの製品を抱えるマネーフォワードクラウドにおいては、共通基盤機能をUI/UXごと再利用性を持たせて切り出せるマイクロフロントエンドは、ビジネスとの相性は良いと思った。3. システムの作りが複雑化することは避けられないので、それなりに組織やシステムが大きくなければ、得られる価値よりも運用コストの方が高そう。4. マイクロフロントエンドに、ベストプラクティスがあるない5. 1チームで複数のマイクロフロントエンドを管理するような状態は間違っている6. 異なるチームのマイクロフロントエンドでブラウザ上の通信が必要な時は慎重にa. 依存関係の管理が必要になって運用難易度が上がるb. データの同期はバックエンドで行う
ご清聴ありがとうございました