DMM ブックスを Next.js 化している話

Transcript

1. DMM ブックスを Next.js 化している話 Think FrontEnd by DMM #09
2. 　　電子書籍開発部 　　　基盤開発グループ 　　　　フロントエンドエンジニア 清水 恭子 - 好き: 漫画/映画/旅行/お酒/辛い物 - 苦手: 日焼け/甘い物 - 推し: リヴァイ兵長/クロス元帥 - 性格: タフ & ポジティブ & マイペース
3. DMM ブックス
4. Think FrontEnd by DMM #03
5. 当時(4年前)にやってたこと
6. 色々あり、こうなっていた ・リプレースと機能開発を交互に実施していたので 　フロントエンド領域は 新旧環境が混在し続けている ・API は別環境に分離
7. 今日の話
8. DMM ブックスを Next.js 化している話
9. 背景課題 ・UX が良くない （遅い・レイアウトシフト激しい） 　　改善施策を打っていたが、リアーキテクトして抜本的な解決がしたい ・FE 開発体感 改善の余地あり 　　React 化したが Routing は BE の持ち物のまま変わらず 　　一つのリポジトリに全てが混在 目的 ・UX 向上（MPA, CSR -> SPA, SSR ） ・FE 開発体感の向上 （Routing を FE 領域へ、 FE/BE 分離） Next.js 化リプレース目的
10. DMM ブックスを Next.js 化している話
11. UX 改善+開発体感向上 のために DMM ブックスを Next.js 化している話
12. PoC ・PHP FW で実装されていた機能が移行 可能か？ ・UX 改善にどういった効果があるか？ ・Next.js AppRouter の採用 　 事前に技術選定と PoC をしていた ・仕様は原則 変えない ・ページ単位 で開発&リリースをしていく リプレース開発の大方針
13. 移植に注力したかったので 現状は部分的な SC, SSR 化 のみ対応 ・レンダリング、ルーティング： Next.js AppRouter 　　SPA 化による回遊時の UX 改善、 　　レンダリング手法の改善やキャッシュ機構の活用による速度改善を期待して採用 ・スタイリング： Styled-Components, CSS Module 　　旧環境が Emotion を採用しており 　　移植コスト低減のために Styled-Components との併用 ・データ管理： TanStackQuery 　　データキャッシュ、ステート管理、 prefetchQuery & HydrationBoundary を使った SSR ・カスタムサーバー： fastify 　　middleware のアクセスログを収集する用 　　 主な技術スタック
14. 前提 ・既存品質を落とさないこと （仕様、UX、セキュリティ、 SEO） ・安定したサービス提供をすること ・計画 　　やることの整理、リリース計画の策定 ・開発（移植、 UX改善） 　　PHP FW が持っていた Routing を Next.js に追加開発 　　既存環境から React コンポーネントを Next.js に移植 　　UX 改善のために Next.js と API 両方で改善検討と実施 ・検証 　　品質担保 : 機能テスト /UX検証/脆弱性診断 /SEO検証 　　安定性担保 : 負荷試験 ・リリース /監視 　　カナリアリリースと A/B テストの実施 　　NewRelic を使った監視 リプレース開発でやっていること
15. 基盤構築と２画面リリースが完了 次のリプレース計画中 今の状況
16. ここまで進めてみてふりかえり
17. ・移植開発 を進めながら API の改善検討 をしていた 　　旧環境をベースにした改善検討になっており、 　　移植完了後に新たな速度ボトルネックが見つかった ・リリースを 全部まとめた 　　改善サイクルが回せなかった 　　施策単位での効果検証が難しかった 　　ビックバンリリース 次からは、、 ・移植 と 改善はなるべく 直列に実施 したい ・リリースはなるべく 最小単位 で実施したい 反省点: 移植と UX 改善の並走
18. よかったこと : 安定的なリリース ができた ・事前に 負荷試験 を実施した 　　検証でわかったパフォーマンスをもとにインフラ設定をした ・カナリアリリース を採用し段階的なユーザー公開をした ( 0% -> 1% -> 10% ,,, ) 　　リスクを抑えながらユーザー公開することができた ・NewRelic ダッシュボード の作成と 日時監視 を行った 　　全員が同じ指標を見ていた 　　異常検知した際にすぐにチームや SRE との連携できた
19. ・基盤構築 とページリプレース のリリースを分けた 　　計画が立てやすかった 　　基盤構築・ページの移植開発それぞれに集中することができた ・極力既存 React コンポーネントを流用（ リファクタ我慢 ） 　OK: 技術スタックの変更による修正や構造の変更 　NG: ロジックやコンポーネントの I/F 修正 　　計画通りに開発が進んだ、デグレートが最小限に抑えられた 　　 よかったこと : 移植開発の 効率化
20. リリースしたものはどうなった？
21. 目的 ・UX 向上（MPA, CSR -> SPA, SSR ） ・FE 開発体感の向上 （Routing を FE 領域へ、 FE/BE 分離） Next.js 化リプレース目的
22. 最善ではないが、、 視覚的 + 指標(LCP,CLS) が改善 し 以前より早く安定した 画面提供ができるようになった Reactバンドル読込 UX改善: Next.js + SSR + API改善による初期描画の変化 Before：画面真白 → 全体スケルトン → ファーストビュー → 書影読込 → 他要素表示 After：ファーストビュー → 書影読込 → 他要素表示 データ fetch 中
23. UX改善: SPA 化 による回遊時の変化 Before After
24. ・BE から脱却 した FE の新環境を構築した！ ・新環境を品質落とさずにリリースして安定稼働させた！ 開発体感の向上 : 新環境の構築と安定リリース
25. ・（当たり前なことかもですが、、） 色々なことを一気にやらない ・UX は今後も改善の余地あり 　活用しきれてない Next.js AppRouter の機能を試したい (Data cahce, レンダリングの最適化 etc..) ・二画面のリリースを経てノウハウ溜まってきたので、 全画面リプレース に向けて頑張る まとめ