出前館Webフロントエンドにおけるリプレイス プロジェクトの取り組みと反省 株式会社出前館 Taiki Shiraishi / 白石 泰己

自己紹介 株式会社出前館 フロントエンドグループ グループマネージャー Taiki Shiraishi / 白石泰己 ユーザー向け Web サイト開発 UI制作が好きなフロントエンドエンジニア

● 個人発表ではなくチームを代表して発表 ● チームの取り組んできた内容について ● チーム構成 12 名 発表の内容について

1 2 3 4 5 目次 PHP から Next.js への刷新 BFF パターンの採用 GraphQL の採用 モノレポの採用 コンポーネントディレクトリの変更

出前館 Web フロントエンドリプレイス ● 開発体制の内製化 ● フロントエンドチーム ● 2021年からビッグ・リライト中 ● PHP + jQueryからNext.jsへの刷新 ○ より効率的な開発が可能 内製化 技術刷新

出前館 Web フロントエンドリプレイス Before Browser PHP App Legacy API Redis DB

出前館 Web フロントエンドリプレース After Browser BFF App Legacy API Redis DB Micro Service A Micro Service B

1 2 3 4 PHPからNext.jsへの刷新理由 フロントエンドチームに PHP 知見ある人が少なかった 既存のコードの保守性の問題 MVCフレームワークでありながらControllerが肥大化 内製化によるPHPの知識不足 フロントエンドのベストプラクティスを適用しやすい環境に バグを減らして、できるだけ早くコードをリリースしたい SSG、SSR、 CSRを同時にできるフレームワークは当時は一択 採用活動にも有利 Reactコミュニティの大きさ

Next.js に満足

1 2 3 BFF(Backend For Frontend)パターンの採用理由 バックエンドのマイクロサービス化 セッション管理 PHP で行っていたセッション管理の構成を引き継ぐ Aggregation Gateway層の必要性 アプリと Web で処理が重複 → BFF で共通化 ● 待ち時間の計算 ● 店舗の商品の時間帯別ソート ● 暗号化/復号化 アプリと Web で 1 つの BFF にすることとした モバイルアプリと Web のロジックの共通化

Good 👍 BFFパターンの採用 その後 ● ViewModel の共通化 ● テストコードもかけた ● フロントチームだけで整形を完結でき る ● 開発組織内でも責務の認識齟齬 ○ ビジネスロジックを持ちオーケストレーション 層だと思われる ● アプリの改修時にもフロントエンドチーム の稼働が発生 ● フロントエンドエンジニアがインフラを構 築・運用管理したり、オブザーバビリティ をきちんとするまでにいたるのには大変 ● 今までブラウザサイドの経験しかないメン バーでやるのは大変 One more 😒

One more 😒 ● 開発組織内でも責務の認識齟齬 ○ ビジネスロジックを持ちオーケストレーション 層だと思われる ● アプリの改修時にもフロントエンドチームの 稼働が発生 ● フロントエンドエンジニアがインフラを構築 ・運用管理したり、オブザーバビリティをき ちんとするまでにいたるのには大変 ● 今までブラウザサイドの経験しかないメンバ ーでやるのは大変 ● BFF という名前が一人歩きしないようにコ ミュニケーションがアーキテクチャ図を作 るべきだった ● Web チームがアプリの人を巻き込んで作る べきだった ● 初期構築時にインフラエンジニアがチーム にいてほしかった ● オブザーバビリティに知見のある人が欲し かった Ideal ✨ BFFパターンの採用 その後

1 2 GraphQLの採用理由 アプリと Web 両方から利用されるため柔軟に利用できるように データオーバーフェッチの削減 リクエストの最適化 クライアントドリブンなアプローチ

Good 👍 GraphQL採用 その後 ● ApolloClient のキャッシュが良い ○ SPA 遷移したときにリフェッチせずキャ ッシュが優先される ● 既存 API の設計に依存し再利用性と柔軟 性が低い ○ GraphQL のベストプラクティスを実現できていな い。 ○ 昔の DB のデータ構造や API の改修になしに GraphQL サーバーだけでは柔軟なデータ構造の構 築には至れなかった ● REST API と変わらぬ設計 One more 😒

One more 😒 GraphQL採用 その後 ● 既存 API の設計に依存し再利用性と柔軟 性が低い ○ GraphQL のベストプラクティスを実現できていな い。 ○ 昔の DB のデータ構造や API の改修になしに GraphQL サーバーだけでは柔軟なデータ構造の構 築には至れなかった ● REST API と変わらぬ設計 ● DB～マイクロサービス まで 1 チームと なりデータ構造を作りたかった ● これからのリアーキテクトに期待 Ideal ✨

1 2 3 monorepo の採用理由 SSRと BFF の負荷を分散することで可用性 UP リスク分散 別サーバーにすることで Web サーバーが動かなくとも BFF が動けばアプリは動く 負荷分散 Next.js の API routes だったため、クライアントサイドとサーバーサイドのコードが混在 より明確なコードベースとディレクトリ構造

Good 👍 monorepo 採用 その後 ● パフォーマンス向上 ● 実際に Web で障害が発生したが、 BFF は稼働し続けた ● クライアントサイドとサーバーサイド でコードベースが分離されてわかりや すく ● Web と同じリポジトリの場合に他チーム がカジュアルに参加できない ● クライアントとサーバーで util 関数など が共通化できておらず、monorepo の良 さを活かしきれていない One more 😒

One more 😒 monorepo 採用 その後 ● Web と同じリポジトリの場合に他チーム がカジュアルに参加できない ● クライアントとサーバーで util 関数など が共通化できておらず、monorepo の良さ を活かしきれていない ● 完全な別リポジトリにすべきだった ● monorepo での共通関数の modules 作成 を最初にすべきだった Ideal ✨

Before Component ディレクトリの変更 src └─components ├─atoms ├─molecules ├─organisms ├─templates └─pages 1. Atomic design の粒度と React Component の粒度が合わない a. Headless な UI はどうすれば🤔 2. Templates と Layouts が役割が重複してい る a. Pages も同じく One more 😒

After Component ディレクトリの変更 src ├ shared ……………………………… # 特定の機能に関心を持たない汎用モジュール群 │ ├ components │ │ ├ functionals ………………… # 見た目に対して関心を持たないコンポーネント群 │ │ └ ui ……………………………… # その他の汎用コンポーネント │ └ hooks ……………………………… # 汎用hooks └ features ……………………………… # 特定の機能に関心を持つモジュール群 ├ shop │ ├ components │ └ hooks └ cart ├ components └hooks

1 2 3 4 改善できる背景 GitHub Discussion や MTG の開催で新しい取り組みへ 前向きに議論 毎週木金に翌週リリースの資材でコア機能のテスト チームでの議論 QA によるリリース判定テスト フロントチームも取り組んでいるがサーバーチームか らも報告がある オブザーバビリティ 自分たちで使って自分たちで直す 社員にユーザーがいる

● チーム内の認識合わせの重要性 ● ビジネス変化や考慮不足による負債は不可避 ● 改善と組織・環境の重要性 ● 新しい取り組みと慎重さのバランス感 まとめ

ありがとうございました！ ご質問などお気軽にお尋ねください。😄