AppRouterを用いた大規模サービス開発におけるディレクトリ構成の変遷と問題点

Think! Frontend #7 の登壇資料です。

Transcript

1. © DMM.com AppRouterを用いた
 大規模サービス開発における
 ディレクトリ構成の変遷と問題点
 eiganken
 1
2. © DMM.com 自己紹介
 eiganken 
 動画配信開発部 Webコアサポートグループ 
 
 動画サービスのフロントエンド開発をしている
 24卒フロントエンドエンジニア
 アニメ・漫画が趣味
 ポケポケ がマイブーム
 （ポケモンカードスマホゲーム） 
 2
3. © DMM.com ターゲット と 目的
 AppRouterで大規模サービス開発している際に発生した
 ディレクトリ構成の問題点を共有する
 ディレクトリ構成について
 考えている方
 大規模サービス開発
 を行う方
 Next.js AppRouter
 を使う方
 3 など

4. © DMM.com アジェンダ
 1. 開発要件と技術選定
 2. 開発当初のディレクトリ構成と問題点
 3. 変更後のディレクトリ構成と問題点
 4. まとめ
 4
5. © DMM.com アジェンダ
 1. 開発要件と技術選定
 2. 開発当初のディレクトリ構成と問題点
 3. 変更後のディレクトリ構成と問題点
 4. まとめ
 5
6. © DMM.com 大規模サービスの開発について
 大規模サービスの
 新規開発
 ➜ 開発人数 (FE以外も込み)
 ➜ 50人以上
 
 ➜ ページ数
 ➜ 約30ページ 
 ✖ クエリパラメータのパターン数
 
 ➜ 現時点でのコンポーネント数
 ➜ 100個以上
 6
7. © DMM.com 開発要件について
 サーバー費用 （サーバー負荷）
 SEO対策
 大規模サービスの
 新規開発
 解決したいこと
 7
8. © DMM.com 開発要件を考慮した技術選定
 サーバー負荷の軽減
 Client Side Rendering
 SEO対策
 Server Side Rendering
 Next.js App Router
 8
9. © DMM.com Client Side Rendering と Server Side Rendering
 Client Side Rendering (CSR)
 ブラウザ上で計算・レンダリング 
 Server Side Rendering (SSR)
 サーバー上で計算・レンダリング 
 9 サーバー負荷を軽減
 SEO対策になる

10. © DMM.com CSR と SSR の切り分け方
 CSR
 SSR
 UserAgent 
 による判定
 アクセス
 Google Bot
 など
 クローラー
 一般ユーザー
 10
11. © DMM.com アジェンダ
 1. 開発要件と技術選定
 2. 開発当初のディレクトリ構成と問題点
 3. 変更後のディレクトリ構成と問題点
 4. まとめ
 11
12. © DMM.com チームでディレクトリ構成を考えるにあたって
 1. CSR・SSRの差分をできるだけなくしたい
 ➜ CSR・SSRさせるコンポーネントをうまく共通化させたい
 
 2. page.tsx がデータリクエストを行う
 ➜ コンポーネント単位でリクエストを行わない
 ➜ まとめてリクエストを行うことで通信回数を減らす
 12
13. © DMM.com 開発当初のディレクトリ構成
 共通範囲によってcomponentsやtypesなどを分ける方法
 https://dir-maker.netlify.app/ 13
14. © DMM.com 開発当初のディレクトリ構成で発生した問題点
 1. Client / Server Component の切り分け
 2. ルールの非制定による複雑化
 14
15. © DMM.com Client Component と Server Component
 15 Client Component 
 
 クライアントでレンダリングされる
 コンポーネント
 Server Component 
 
 サーバーでレンダリングされる
 コンポーネント

16. © DMM.com 問題点：Client / Server Component の切り分け
 ➜ Server Component は Client Component から利用する時は
 気をつける必要がある
 
 ➜ 正しくBot向け（SSR）にレンダリングされない可能性がある
 ➜ SEOに影響がでてしまう可能性がでてくる
 
 ➜ コンポーネントを追加する際に、常にServerかClientかを意識する必要があり、 コストがかかる
 16
17. © DMM.com 問題点：ルールの非制定による複雑化
 ➜ ディレクトリ構造に関する軽いルールだけでもっと細かいルールを制定 しなかった
 
 ➜ 開発者がさらに増えると、より複雑性が増す
 ➜ 1ディレクトリ内でばらつきが出てしまう
 ➜ 依存関係が複雑化してしまい、共通化がしにくくなる
 17
18. © DMM.com アジェンダ
 1. 開発要件と技術選定
 2. 開発当初のディレクトリ構成と問題点
 3. 変更後のディレクトリ構成と問題点
 4. まとめ
 18
19. © DMM.com 改善案：Monorepoによるディレクトリ構成
 責務を分類し、Monorepo化によってディレクトリを構成する方針に変更
 19
20. © DMM.com apps
 packages
 apps と packages の依存関係について
 ui
 infra
 domain
 utils
 bot
 user
 ➔ apps は packages を利用
 
 
 
 ➔ packages 内でもそれぞれの 依存関係を制定
 
 20
21. © DMM.com 改善後のディレクトリ構成で発生した問題点
 1. hooksによる Client Component化
 2. propsのバケツリレー
 21
22. © DMM.com 問題点：hooksによるClient Component化
 ➜ インタラクティブなUIは useState, useEffect を使うため “use client” が
 必要になる
 ➜ 適当に “use client” を付けると、コンポーネント内全体が Client Component になっ てしまう 
 
 ➜ Server Component で良い部分も無駄に Client Component になってしまう
 22
23. © DMM.com CSR/SSR共通のUIコンポーネントの適切な管理
 ➜ CSR, SSR 共通の UIコンポーネントでは、適切な管理を検討したい
 23 イメージ

24. © DMM.com 問題点：props のバケツリレー
 ➜ ページで取得した値をバケツリレーでコンポーネントに渡している
 ➜ 末端の子コンポーネントに必要な props を追加すると、依存しているコン ポーネントのpropsの修正が必要になる
 24
25. © DMM.com Storesの追加
 ➜ 以下を担う stores を追加する
 ➜ 状態管理
 ➜ React Provider
 25
26. © DMM.com アジェンダ
 1. 開発要件と技術選定
 2. 開発当初のディレクトリ構成と問題点
 3. 変更後のディレクトリ構成と問題点
 4. まとめ
 26
27. © DMM.com まとめ
 ➜ 以下の課題も見えてきたが、 Monorepo化によるディレクトリ
 構成・依存関係の整理により複雑にはならなくなった
 
 ➜ “use client” を用いた ClientComponent化や useState, useEffectに関するエ ラーに気を付ける
 ➜ ページでデータ取得をprops の受け渡しが 状態管理やReact Provider を活用 して複雑性を下げる
 上記の問題は改善ができそうなので改善していきたい 💪
 27
28. © DMM.com ご清聴ありがとうございました🙌
 懇親会もぜひお楽しみ下さい！
 28