出前館Webフロントエンドリプレイスプロジェクトの取り組みと反省について

Transcript

1. 出前館Webフロントエンドにおけるリプレイス プロジェクトの取り組みと反省 株式会社出前館 Taiki Shiraishi / 白石 泰己
2. 自己紹介 株式会社出前館 フロントエンドグループ グループマネージャー Taiki Shiraishi / 白石泰己 ユーザー向け Web サイト開発 UI制作が好きなフロントエンドエンジニア
3. • 個人発表ではなくチームを代表して発表 • チームの取り組んできた内容について • チーム構成 12 名 発表の内容について
4. 1 2 3 4 5 目次 PHP から Next.js への刷新 BFF パターンの採用 GraphQL の採用 モノレポの採用 コンポーネントディレクトリの変更
5. 出前館 Web フロントエンドリプレイス • 開発体制の内製化 • フロントエンドチーム • 2021年からビッグ・リライト中 • PHP + jQueryからNext.jsへの刷新 ◦ より効率的な開発が可能 内製化 技術刷新
6. 出前館 Web フロントエンドリプレイス Before Browser PHP App Legacy API Redis DB
7. 出前館 Web フロントエンドリプレース After Browser BFF App Legacy API Redis DB Micro Service A Micro Service B
8. 1 2 3 4 PHPからNext.jsへの刷新理由 フロントエンドチームに PHP 知見ある人が少なかった 既存のコードの保守性の問題 MVCフレームワークでありながらControllerが肥大化 内製化によるPHPの知識不足 フロントエンドのベストプラクティスを適用しやすい環境に バグを減らして、できるだけ早くコードをリリースしたい SSG、SSR、 CSRを同時にできるフレームワークは当時は一択 採用活動にも有利 Reactコミュニティの大きさ
9. Next.js に満足
10. 1 2 3 BFF(Backend For Frontend)パターンの採用理由 バックエンドのマイクロサービス化 セッション管理 PHP で行っていたセッション管理の構成を引き継ぐ Aggregation Gateway層の必要性 アプリと Web で処理が重複 → BFF で共通化 • 待ち時間の計算 • 店舗の商品の時間帯別ソート • 暗号化/復号化 アプリと Web で 1 つの BFF にすることとした モバイルアプリと Web のロジックの共通化
11. Good 👍 BFFパターンの採用 その後 • ViewModel の共通化 • テストコードもかけた • フロントチームだけで整形を完結でき る • 開発組織内でも責務の認識齟齬 ◦ ビジネスロジックを持ちオーケストレーション 層だと思われる • アプリの改修時にもフロントエンドチーム の稼働が発生 • フロントエンドエンジニアがインフラを構 築・運用管理したり、オブザーバビリティ をきちんとするまでにいたるのには大変 • 今までブラウザサイドの経験しかないメン バーでやるのは大変 One more 😒
12. One more 😒 • 開発組織内でも責務の認識齟齬 ◦ ビジネスロジックを持ちオーケストレーション 層だと思われる • アプリの改修時にもフロントエンドチームの 稼働が発生 • フロントエンドエンジニアがインフラを構築 ・運用管理したり、オブザーバビリティをき ちんとするまでにいたるのには大変 • 今までブラウザサイドの経験しかないメンバ ーでやるのは大変 • BFF という名前が一人歩きしないようにコ ミュニケーションがアーキテクチャ図を作 るべきだった • Web チームがアプリの人を巻き込んで作る べきだった • 初期構築時にインフラエンジニアがチーム にいてほしかった • オブザーバビリティに知見のある人が欲し かった Ideal ✨ BFFパターンの採用 その後
13. 1 2 GraphQLの採用理由 アプリと Web 両方から利用されるため柔軟に利用できるように データオーバーフェッチの削減 リクエストの最適化 クライアントドリブンなアプローチ
14. Good 👍 GraphQL採用 その後 • ApolloClient のキャッシュが良い ◦ SPA 遷移したときにリフェッチせずキャ ッシュが優先される • 既存 API の設計に依存し再利用性と柔軟 性が低い ◦ GraphQL のベストプラクティスを実現できていな い。 ◦ 昔の DB のデータ構造や API の改修になしに GraphQL サーバーだけでは柔軟なデータ構造の構 築には至れなかった • REST API と変わらぬ設計 One more 😒
15. One more 😒 GraphQL採用 その後 • 既存 API の設計に依存し再利用性と柔軟 性が低い ◦ GraphQL のベストプラクティスを実現できていな い。 ◦ 昔の DB のデータ構造や API の改修になしに GraphQL サーバーだけでは柔軟なデータ構造の構 築には至れなかった • REST API と変わらぬ設計 • DB～マイクロサービス まで 1 チームと なりデータ構造を作りたかった • これからのリアーキテクトに期待 Ideal ✨
16. 1 2 3 monorepo の採用理由 SSRと BFF の負荷を分散することで可用性 UP リスク分散 別サーバーにすることで Web サーバーが動かなくとも BFF が動けばアプリは動く 負荷分散 Next.js の API routes だったため、クライアントサイドとサーバーサイドのコードが混在 より明確なコードベースとディレクトリ構造
17. Good 👍 monorepo 採用 その後 • パフォーマンス向上 • 実際に Web で障害が発生したが、 BFF は稼働し続けた • クライアントサイドとサーバーサイド でコードベースが分離されてわかりや すく • Web と同じリポジトリの場合に他チーム がカジュアルに参加できない • クライアントとサーバーで util 関数など が共通化できておらず、monorepo の良 さを活かしきれていない One more 😒
18. One more 😒 monorepo 採用 その後 • Web と同じリポジトリの場合に他チーム がカジュアルに参加できない • クライアントとサーバーで util 関数など が共通化できておらず、monorepo の良さ を活かしきれていない • 完全な別リポジトリにすべきだった • monorepo での共通関数の modules 作成 を最初にすべきだった Ideal ✨
19. Before Component ディレクトリの変更 src └─components ├─atoms ├─molecules ├─organisms ├─templates └─pages 1. Atomic design の粒度と React Component の粒度が合わない a. Headless な UI はどうすれば🤔 2. Templates と Layouts が役割が重複してい る a. Pages も同じく One more 😒
20. After Component ディレクトリの変更 src ├ shared ……………………………… # 特定の機能に関心を持たない汎用モジュール群 │ ├ components │ │ ├ functionals ………………… # 見た目に対して関心を持たないコンポーネント群 │ │ └ ui ……………………………… # その他の汎用コンポーネント │ └ hooks ……………………………… # 汎用hooks └ features ……………………………… # 特定の機能に関心を持つモジュール群 ├ shop │ ├ components │ └ hooks └ cart ├ components └hooks
21. 1 2 3 4 改善できる背景 GitHub Discussion や MTG の開催で新しい取り組みへ 前向きに議論 毎週木金に翌週リリースの資材でコア機能のテスト チームでの議論 QA によるリリース判定テスト フロントチームも取り組んでいるがサーバーチームか らも報告がある オブザーバビリティ 自分たちで使って自分たちで直す 社員にユーザーがいる
22. • チーム内の認識合わせの重要性 • ビジネス変化や考慮不足による負債は不可避 • 改善と組織・環境の重要性 • 新しい取り組みと慎重さのバランス感 まとめ
23. ありがとうございました！ ご質問などお気軽にお尋ねください。😄