実践！Micro Frontends！~ kintone の共通ヘッダーは独立したデプロイの夢を見るか? ~

BuriKaigi2024 での発表資料です。異なるフレームワークが共存する画面を Micro Frontends のアプローチを用いて部分刷新した事例についてご紹介します

Outline/Structure of the Talk
1. Micro Frontends の概要
2. kintone の全画面のヘッダーを刷新するときに生じた問題
3. 選択した結合方法とその理由
4. 得られた効果
5. 刷新した共通ヘッダーの今

Learning Outcome
* 大規模なソフトウェアの分割方法・組織アプローチ
* Client Side Composition のパターンとそれぞれのメリデメ

Target Audience
* 大規模なソフトウェアの分割方法・組織アプローチに興味のある方
* Micro Frontends の実践事例を知りたい方

Transcript

1. ~ kintone の共通ヘッダーは独立したデプロイの夢を見るか? ~ 実践！Micro Frontends！ BuriKaigi 2024 もやし丸
2. About Atusuke Murata (もやし丸) サイボウズ株式会社 Scrum Master / Software Engineer @kuroppe1819
3. Agenda Micro Frontends の概要 1. kintone の全画面のヘッダーを刷新するときに生じた問題 2. 選択した結合方法とその理由 3. 得られた効果 4. 刷新した共通ヘッダーの今 5.
4. Learning Outcome 大規模なソフトウェアの分割方法・組織アプローチ Client Side Composition のパターンとメリデメ Target Audience 大規模なソフトウェアの分割方法・組織アプローチに興味のある方 Micro Frontends の実践事例を知りたい方
5. Micro Frontends の概要
6. Micro Frontends の概要 モノリスアプリケーションをフロント エンドも含めてより小さくシンプルな 塊に分解し、独立して開発、テスト、 デプロイできるようにしながらも、顧 客には1つのまとまった製品として見 せる組織アプローチ それぞれのチームが一つの機能を提供 すべく、DB から UI まで一連の開発・ 運用を行う Fig. 55 Monolithic Frontends - micro-frontends.org
7. Micro Frontends のメリデメ インクリメンタルアップグレード シンプルで分離されたコードベース 独立したデプロイ 自律したチーム メリット デメリット ペイロードサイズの肥大化 運用とガバナンスの複雑さ
8. 分割した機能を結合するパターン Client Side Composition iframe による結合 JavaScript によるランタイム結合 Web Components によるランタイム結合 Server Side Composition Build Time Composition Edge Side Composition
9. 参考資料 Micro Frontends - extending the microservice idea to frontend development https://micro-frontends.org/ Micro Frontends https://martinfowler.com/articles/micro-frontends.html Micro Frontends In Action https://livebook.manning.com/book/micro-frontends-in-action
10. kintone の共通ヘッダーを 刷新する際に生じた問題
12. 赤枠で囲った部分が共通ヘッダーの領域 kintone の共通ヘッダー
13. 共通ヘッダーの刷新計画 React化済みのページにのみ 共通ヘッダーを提供する 1段階目 2段階目 kintone の全画面の共通 ヘッダーを刷新する
14. 提供先の画面に合わせてリリース フローを選択する必要が出てきた Closure Tools では Closure Compiler という独自のコンパイラ を用いて配布用の JavaScript を生 成するため、npm で配布されたパ ッケージとビルド時に結合するこ とが困難 npm パッケージとして配布する場 合、デプロイがパッケージを取り 込む側のタイミングに依存する 2段階目に差し掛かったタイミングで問題発生！ npm package として配布
15. クライアントサイドの結合に移行する JSファイルを配布 ビルドしたJSファイルを配布 してブラウザで結合する 提供先の画面に依存せず、自 チームでリリースをコントロ ールできるようになる チームの敏捷性が高まる
16. Client Side Composition を試す
17. 結論 (Client Side Composition) iframe による結合 → ❌ JavaScript によるランタイム結合 → ⭕️ Web Components によるランタイム結合 → ❌
18. JavaScript によるランタイム結合を採用した
19. iframe を採用しなかった理由 iframe の中のコンテンツが iframe の高さに制限される。コンテンツの 量に応じて高さを動的に変更することが難しい CPUやメモリの消費量が大きいのでパフォーマンスが悪い ページのセマンティックな構造を破壊するため、アクセシビリティ的に よろしくない
20. Web Components を採用しなかった理由 共通ヘッダーを Web Componens 化 したときに、Shadow DOM の外側に ある要素を参照しているロジックが動 かなくなる。style も適用されない。 (例: body 直下にマウントされる Dialog コンポーネント) コンポーネントのカプセル化は魅力的 だが、既存実装を変更してまで実現し たいものではない ❌
21. JavaScript によるランタイム結合 サーバーが返す各ページの HTML に共通ヘッダーをレンダリングするための DOM と JS を埋め込む index.html commoon-header.js
22. ヘッダーとページコンテンツ間の通信 共通ヘッダーとページコンテンツ間でやり取りする必要のある機能(例: 通知)に ついては Custom Event を使う
23. 得られた効果 共通ヘッダーの提供先に依存しない 独立したデプロイが可能 メリット デメリット ライブラリの重複読み込みによる パフォーマンスの低下
24. 共通ヘッダーの今 2023年11月に本番環境での移行が完了した 新規機能を開発しているチームにコードとオーナーシップを移譲した
25. kintone の共通ヘッダーを部分刷新して得られた学び https://blog.cybozu.io/entry/2023/12/25/120000_1