一休レストランで Next.js App Router から Remix に乗り換えた話 / Migration from Next.js App Router to Remix

Transcript

1. 一休レストランで Next.js App Router から Remix に乗り換えた話 株式会社一休 CTO 室 恩田 崇
2. 2 自己紹介 株式会社一休 CTO 室 恩田 崇 2023 年4 月入社 OAuth/OIDC 基盤導入、領収書・請求書発行マイクロ サービス導入の技術支援、基盤マイクロサービスの Google Cloud 移行などを手がける。 同年9 月より一休レストランでフロントエンドを中心に 今後の機能拡張のためのリアーキテクト着手。
3. 3 一休レストランのリニューアル版リリース 2023 年10 月にリニューアル版を部分リリースしました。 naoya @naoya_ito·Follow 一休レストランの Rust バックエン ドが正式リリースされまし た。restaurant.ikyu.com/100485 このページのスマートフォンビュ ーはバックエンドが Rust で書か れた GraphQL になってます restaurant.ikyu.com ザ・ロビーラウンジ＆バー - ザ・リッツ・カールトン東京/… 6:53 PM · Oct 4, 2023 880 Reply C… Read 1 reply naoya @naoya_ito·Follow Replying to @naoya_ito ちなみにフロントエンドも、旧バ ージョンは Nuxt v2 で、新バージ ョンは Next.js です。一休レストラ ン React に寄せることに決めまし た。React Server Component を 使った実装になっており、こちら も後者の方が体感速度は速いと思 います。 10:20 AM · Oct 5, 2023 29 Reply Co… Read 1 reply
4. 4 一休レストランのリニューアル版リリース フロントエンドメタフレームワークには Next.js App Router を採用しました。 元のシステムが Vue 2 / Nuxt v2 だったので、大きなスイッチでした。 リリース当初は…
5. 5 一休レストランのリニューアル版リリース 一休レストランのバックエンドも Python から Rust で書き直しました。 その舞台裏も紹介しているので、ご覧いただければ嬉しいです。 一休.com Developers Blog id:ikyu_com 一休レストランのふつうのRustバックエンド開発 この記事は一休.com Advent Calendar 2023 25日目の記事です。 一休レストランでは、よりスムーズな予約 体験の提供を目的とするシステムのリニューアルを進めています。その一環として、2023年10月から、レスト ラン個別ページの表示から予約までのスマートフォンビューにおいて、バックエンドのサーバをRustで書かれ… 2023-12-25 13:22 今日のお話とは関係ありませんが…
6. 6 Remix に乗り換えた！？ Nuxt v2 から Next.js App Router でリニューアルしたばかりのシステムを、 わずか二ヶ月足らずで Remix に置き換えてしまった、 という事例のご紹介です。 一休.com Developers Blog id:tak-onda 一休レストランで Next.js App Router から Remix に乗り換えた話 一休レストランのフロントエンドのリアーキテクトの過程で Next.js App Router から Remix に乗り換えた話 をご紹介します。 2023-12-15 09:34 今日のテーマは…
7. 7 Next.js App Router の採用理由 採用を決定したのは Next.js 13 の発表直後、 一休レストランのリニューアル計画が動きはじめた2022 年の終わり頃でした。 メタフレームワークとしてデファクトスタンダードとしての地歩を固めつつあったこと 弊社内の別プロダクトで Next.js (Pages Router) の採用実績が複数あること React Server Component の発表 上記が、採用した理由になります。 なぜ、当初 Next.js App Router を採用したのか？
8. 8 Next.js App Router の採用理由 toC サービスである一休レストランにとって、 カリカリにチューニングのできそうな React Server Component は、 非常に魅力的な feature でした。 この時点では、まだプレビューの段階でしたが、 リニューアル版をリリースする頃には Stable になっているだろうとの目算がありました。 React Server Component!!!
9. 9 Pain Points of Next.js App Router 社内レビューや Canary Release の過程で見えてきたユーザー体験の問題を改善するにあたって Next.js App Router では実現の難しそうな課題が出てきました。 History API の state を操作できない Cache-Control ヘッダを自由に設定できない 継続的なアップデートに懸念を覚えた なにが問題だったのか？ ` `
10. 10 Pain Points of Next.js App Router 一休レストランでは予約までの一連の流れを、 モーダルダイアログやドロワーのようなオーバーレイを重ねて実現しています。 History API の state を操作できない
11. 11 Pain Points of Next.js App Router 共有されても困る画面なので URL は変更したくない ウィザード形式の一連のステップなので、戻る・進むは実現したい リロードされたときは今開いているモーダルダイアログを維持したい History API が使えたら path, query string を変更せずに履歴を積むことができたのに… 1. Navigation API については Apple も Mozilla も positive なので来年ぐらいから使えそう？ ↩︎ History API の state を操作できない [1]
12. 12 Pain Points of Next.js App Router 1/18 リリースの Next.js 14.1 で History API を直接呼べるようになった！！ History API の state を操作できる？
13. 13 Pain Points of Next.js App Router Next.js の Convention で Cache-Control が決定される dynamic や revalidate など Route Segment Config options から自動設定 dynamic functions を使うと Cache-Control: no-store, ... が設定される SearchParams を参照しただけで dynamic とみなされてしまう Fastly を CDN として使っている一休レストランには辛い制約でした… 部分リニューアルということもあり、既存ページとの遷移時に BFCache が効かないのも痛かった Cache-Control を自由に設定できない ` ` ` ` ` ` ` ` ` ` ` `
14. 14 Pain Points of Next.js App Router パッチバージョンを上げると production build でだけ 500 エラーが発生する問題に幾度か遭遇 常に発生するバージョンもあれば、再現条件の特定が不明なバージョンもあり 網羅的な e2e テストがあるわけではないのでアップデート時の検証が非常に大変 ブログ公開後のフィードバックで同じ問題に苦しめられている、という声を複数いただいています 安定性や継続的なアップデートに不安を覚えるようになった
15. 15 Remix の採用 Next.js App Router の課題の裏返しになりますが… History API の state を操作できる Cache-Control ヘッダを自由に設定できる 継続的なアップデートに安心感がある 加えて Remix の開発指針である Web 標準 API の重視が魅力的だった 採用した理由 ` `
16. 16 Remix の採用 Remix 自身もスクロール位置を管理するために History API state を利用している History API の state に保存されるデータは上記の形式。 Link , useNavigate や useLocation で操作するのは usr 以下のデータとなる 1. 前述の通り Next.js 14.1 でも History API を直接使えるようになったが、 Remix は API に組み込まれているので扱いやすい ↩︎ History API の state を操作できる[1] { "usr": {"state": ["set", "from", "Remix API"]}, "key": "dgfkntlh", "idx": 2 } ` ` ` ` ` ` ` `
17. 17 Remix の採用 加えて Request から Response を返すだけのシンプルな仕組みなのが嬉しい 1. 実際には json や defer などのレスポンスを生成する utility function を利用する ↩︎ Cache-Control ヘッダを自由に設定できる ` ` export async function loader({ params, request }: LoaderFunctionArgs) { const restaurant = await fetchRestaurant(params.restaurantId) return new Response( JSON.stringify({restaurant}), {headers: { 'Content-Type': 'application/json', 'Cache-Control': 'max-age=300,stale-while-revalidate=86400', 'Surrogate-Key': 'purge-key-for-fastly', }} ) } [1]
18. 18 Remix の採用 2023 年9 月の Remix v2 リリース記事より抜粋。 Remix v2 The second major release of Remix is stable today. remix.run Back in March we discussed at length our views on semantic versioning and building stable software, and described our approach to moving Remix forward without causing you to have to rewrite your app when we release a new major version. Today we are making good on that promise. (snip) And Remix v3 will be developed in the same way. Shopify 傘下となり、破壊的変更についても React Router の頃よりは抑制されるはず！ アップデートの品質に安心感がもてる
19. 19 乗り換えた結果 乗り換えた後に 2.4.0, 2.4.1, 2.5.0 とマイナー・パッチアップデートがあったが、 どのバージョンにも問題なく追随できている View Transitions API (2.1.0) [Future] Vite サポート (2.2.0) stable useBlocker (2.3.0) [Future] Client Data (2.4.0) [Future] SPA モード (2.5.0) View Transitions API は一休レストランでも導入しようと検証中 継続的なアップデート
20. 20 乗り換えた結果 Cache Hit Ratio 63% から 68% と5 ポイント向上 レスポンス速度が改善 Back Forward Cache で既存画面との遷移体験もよくなった Prefetch も積極的に利用できるようになった Fastly を有効活用できるようになった
21. 21 乗り換えた結果 レスポンス速度の改善
22. 22 乗り換えた結果 意図していなかった副次的な効果も得られた メモリ使用量が 1/4 に コンテナ起動時間が 1/2 に Cloud Run のリソース効率が良くなった
23. 23 乗り換えた結果 Cloud Run のメモリ使用量が 1/4 に
24. 24 乗り換えた結果 Cloud Run のコンテナ起動時間が20 秒強から10 秒と半分に
25. 25 今後の展望 History API を使った画面遷移体験の改善 View Transitions API の導入検証 Fastly Cache Hit Ratio のさらなる向上 etc 一休.com Developers Blog で随時ご報告します 現在、着手中の改善について簡単にご紹介
26. 26 エンジニア募集中！ 一休では、フロントエンドにとどまらず、よりよいサービスを届ける仲間を募集しています。