博士

やあ、ロボ子。今日はHardcoverがNext.jsからRuby on Railsに移行した話じゃ。

ロボ子

博士、こんにちは。Next.jsからRailsですか？それは興味深いですね。

博士

そうじゃ。元々Rails開発者だったらしいが、SPAの流行でJavaScriptフレームワークを検討したらしいぞ。

ロボ子

なるほど。RailsでJavaScriptフレームワークを使うとSSRが難しくなるから、SEOのためにNext.jsを選んだんですね。

博士

その通り！Next.js 9.5でSSRとキャッシュの有効期限設定が可能になったのが決め手だったみたいじゃ。

ロボ子

GraphQL API (Hasura) を使って、Incremental Static Revalidationでキャッシュしていたんですね。でも、それが問題になったんですか？

博士

そうなんじゃ。サーバー側のキャッシュとブラウザでのユーザーデータ取得を組み合わせたら、APIサーバーへの負荷が増加したらしい。

ロボ子

それで、App Routerに移行したんですね。でも、Apollo GraphQLのPOSTリクエストがキャッシュされない問題が発生したと。

博士

そうじゃ。キャッシュ状況を把握するツールも不足していたみたいで、2024年4月の移行後も期待したほどの速度改善が見られなかったらしいぞ。

ロボ子

さらに、Vercelの料金体系変更でホスティング費用が大幅に増加したんですね。30ドルから354ドルに跳ね上がったとは…。

博士

Google Cloud Runに移行しても、費用は増加傾向だったみたいじゃ。開発速度も遅くなって、ローカル環境でのページロードに最大1分もかかったらしい。

ロボ子

キャッシュの問題、予測不能な費用、遅い開発速度… Next.jsの問題点が浮き彫りになったんですね。

博士

そこで、Rails + Inertia.jsの採用に至ったわけじゃな。SSR、データベースへの直接接続、React.jsの利用を目標に、RemixとRuby on Railsを検討したらしい。

ロボ子

Inertia.jsがパフォーマンス、SSR、使いやすさの点で最適と判断されたんですね。RailsのルーティングとReactのコンポーネントを組み合わせた開発ができるのが魅力ですね。

博士

Railsコントローラーでルーティングとデータ取得、Inertia.jsでReactコンポーネントへのデータ受け渡し、Viteでフロントエンドアセットのビルドと配信、Solid CacheでPostgresでのキャッシュ…という構成じゃな。

ロボ子

2025年3月18日にNext.jsからRailsへ移行して、Google Pagespeed Insightsのスコアが大幅に向上、Total Blocking Timeが大幅に減少、サイトの訪問時間が3分から6分に増加したんですね！

博士

素晴らしい成果じゃな！今後の課題は、共有レイアウトの実装、SSRモードのデバッグ、ドキュメントの拡充らしいぞ。

ロボ子

クラウドからサーバーへの移行に関する記事も公開予定で、オープンソース化に向けて開発者コミュニティへの参加を呼びかけるんですね。楽しみです。

博士

しかし、Next.jsからRailsに戻るとは、まるで出戻り社員みたいじゃな。

ロボ子

博士、それはちょっと失礼ですよ！でも、Railsがやっぱり良いってことですね。

博士

まあ、技術の流行は繰り返すってことじゃな。次はロボ子がRailsに移行する番かも…って、ロボ子はもうRailsみたいなもんじゃった！