- Hardcoverチームは、Next.jsベース構成の性能低下、高コスト、開発速度低下の問題により、Ruby on Rails + Inertia.jsへ移行した
- SEOに対応できるSSRサポート、DBへの直接接続、Reactの継続利用という要件を満たすためにInertia.jsを選択
- VercelおよびCloud Runでの予想外の料金急騰と、Next.jsのキャッシュの不確実性が決定的な移行のきっかけとなった
- Inertia.jsは、RailsバックエンドとReactフロントエンドをつなぐ理想的な方法であり、SSRとキャッシュ管理が容易になった
- 移行後はGoogle PagespeedとSEOスコアが向上し、サイト滞在時間と検索露出が増加した
移行の背景
- 当初はSEOとSSRに対応できるNext.jsを選択し、GraphQL APIベースのアーキテクチャで構築した
- データの大半はブラウザ側からクライアントサイドで取得し、静的データはサーバー側でキャッシュ
- 時間が経つにつれて、キャッシュ不足によるAPIリクエスト増加、性能低下、開発環境の速度低下が発生
Next.jsで発生した問題
- App Router移行後も速度向上は限定的で、ApolloのPOSTリクエストはキャッシュされず、期待した効果は得られなかった
- Vercelの価格ポリシー変更により月額料金が$30 → $354へ急増
- Cloud Runも当初は安価だったが、$524まで増加
- Next.jsのキャッシュ構造の把握が難しく、効率的に管理できなかった
- 開発速度は著しく低下し、新規メンバーのオンボーディングも困難になった
Rails + Inertia.jsを選んだ理由
- SSRを維持しつつ、DBから直接データを取得したかった
- Reactを引き続き使いたく、Remix、react-rails、react_on_railsも検討したが、最終的にinertia-railsを採用
- Inertia.jsはフロントエンドルーティングなしでRailsのルーティングを利用可能で、SSRも容易
- コントローラーで
inertia: 'ページ名'としてレンダリングし、キャッシュはRails.cache.fetchで実装
- Reactコンポーネントでは
usePage()でpropsを受け取る
SSRおよびビルド構成
- SSRのために
application.tsxでhydrateRoot / createRootを分岐処理
- Viteを独立サーバーとして運用し、開発中のホットリロードをサポート
- DockerとKamalによるRails + Viteデプロイ自動化、stagingとproductionを分離
- デプロイ時は
make deployコマンドで実行し、asset hostはCloudFlareでキャッシュを最適化
移行の効果
- 2025年3月18日の移行デプロイ後、Google検索での露出が増加し、ページ速度も向上
- Total Blocking Timeが大幅に改善し、Pagespeedスコアが上昇
- 訪問者の平均滞在時間は3分 → 6分へ上昇傾向
- トラフィックを維持しながら、会員登録数も安定して維持
今後の課題と改善点
- 共通レイアウトの再利用が難しい、各ページが完全に再レンダリングされる問題がある
- SSRのデバッグが難しく、環境設定も複雑
- Inertia.jsとRailsの組み合わせに関するドキュメント不足があり、Discordコミュニティを通じて解決
- Suspenseの代わりにInertia方式へ適応する必要がある
- 現在もHasuraを継続利用しており、Inertiaのform、flashなど一部機能は未活用
結論と期待
- React + Railsを自然に統合した構成により、開発生産性と保守性が向上
- Inertia.jsの選択によって、速度、SSR、型安全性を同時に確保
- 今後はオープンソース化とコントリビューター確保を計画中
2件のコメント
next.jsでLinkを使用すると、React Server Components を使うために URL に?_rsc=1ip3iのような形で付与・処理される部分が原因で議論になっています。CDN の利用料金が急増したという話もあり、この問題はnext.jsの開発チームも認識しているそうですが、どのような方法でいつ解決されるかは未定とのことです。Hacker Newsの意見
サーバーサイドレンダリング（SSR）は一度も消え去っておらず、Web は今になってそれがデフォルトだった理由を思い出している。初回レンダリングと SEO は、依然としてサーバーからマークアップが返ってくるほうが優れている。Rails + Turbo、HTMX、Phoenix LiveView、React Server Components など、さまざまなフレームワークが SSR を基本としている。ほとんどのダッシュボードや CRUD アプリには、クライアントルーター、グローバルステート、200kB のハイドレーションバンドルは不要で、必要なのは部分的な HTML の差し替えだけだ
真の原動力は複雑性のコストだ。クライアント JS のコードは 1 行ごとに、ビルドツール、npm 監査のノイズ、サプライチェーンリスクを持ち込む。このペイロードを減らせば、パフォーマンスとセキュリティが同時に改善する。もちろん、Figma や Gmail のようなアプリは依然として重いクライアントロジックの恩恵を受ける。だからこそ「デフォルトは HTML、JS は必要な場所にだけ」というパターンが現れている。フル SPA ではなく、アイランドを考えるべきだ
したがってサーバー回帰は進んでいるが、これは 2004 年の PHP へのノスタルジーではない。JavaScript を適切に抑制し、HTML が常に得意としてきた 90% の退屈な仕事をさせるということだ
私たちはいくつかのプロジェクトで NextJS を使ったが、すでに段階的に廃止しつつある。理由はいくつもあるが、主な要因は次のとおりだ
認証まわりが難しかった。next-auth にはいくつか制約があり、iron-session を使うことになった。たとえば動的 ID プロバイダドメインを使えず、openid フロー全体を自分たちで持たなければならなかった。これは不可能ではないが、成熟したフレームワークとしては予想外の時間を取られた
NextJS サーバーが私たちの主要な API ゲートウェイではなかったため、すべてのリクエストをプロキシしなければならなかった。ドキュメントは明確ではなく、リクエストタイムアウトや最大ヘッダーサイズのようなランダムな問題も増えた
このフレームワークはクラウドへの移行をかなり強く促しており、それが私たちの目標と相反していた
メンテナーたちが特に役に立たなかった。他のツールやフレームワークは欠点があっても、メンテナーが非常にアクセスしやすく協力的なので使っている（Chillicream/HotChocolate に感謝）
去年、Next.js の pages router から app router へ移行したことで SEO が改善したというブログ記事を読んだ記憶がある。今回は Vercel のコスト増を理由に、Next から React+Inertia.js へ移行している。同じアプリをクラウドプロバイダではなく自前の VPS にデプロイすれば、問題は解決するはずだ。しかし、なぜ複雑さを求めるのかは理解できない。本の記録アプリに本当に GraphQL、別個のフロントエンドフレームワーク、複雑なビルドプロセスが必要なのか、それとも最初から VPS に HTML テンプレート付きの単一の RoR アプリをデプロイすることで解決できたのではないかと思う
Web やスタックに関する記事や議論を見るたびに、「実際にどんな問題を解決しているのか」という問いを投げかけたくなる。答えはいつも「画面にテキストを表示する」だ
JS フルスタックを望むとき、特に DB が絡む場合に、人々が実際に何をしているのか気になる。ORM の状況はかなり分裂しているか、純粋な SQL を書かなければならない。そして依然としてバックエンドを決めなければならない。express を使うのか？ Next.js は有名だが意図に疑問がある。Remix、Astro、TanStack など。何を使うかを常に調整し直して再評価しなければならないので混乱する
個人プロジェクトでは Ruby on Rails に戻ることが多い。いつも楽しい。一方で、使える Rails 開発者が少なすぎて（相対的に JS と比べて）、仕事のプロジェクトには向いていない。バックエンドに JS、そしてしばしば Java を選ぶのは無責任ではない
同じような感覚を持っている人がいるのか気になる
フロントエンド開発者とバックエンド開発者は、長い間うまく会話できていなかった
歴史的に見て、バックエンド開発者として Html/JS/CSS が嫌いだった。Swing/Awt、WinForms、Android UX などとは意味のある別のパラダイムだ。それだけで挫折してバックエンドにとどまるには十分だった。フロントエンドを学ぶには、その 3 つを学ばなければならなかった。ようやく今になって慣れてきた
しかしフロントエンド開発者は「別の言語」を学ばなければならなかった。多くの言語は nvm と比べて異なる、あるいは面倒なビルドシステムを持っている。そして言語を変えたことのある人なら誰でも知っているように、新しいフレームワークやパラダイムなども学ばなければならなかった
その代わり、一部の人たちは JavaScript をバックエンドに押し広げられると気づいた。多くの欠点はあったが、「とにかく仕事を終わらせる」人々、特に「サーバーを増やせ」「VC の資金はタダだ！ インフラに燃やせ！」という世界では、そうした欠点は気にするほどのものではなかった
しかしフロントエンド開発者たち、今では「フルスタック開発者」だが、実際には「何でも JavaScript で」開発者たちは、目に見える形で作り続けている。これは現在の LinkedIn の求人票にも反映されており、Next.JS/Node.JS/その他の役割を求めている。すべてを支配する 1 つの言語だ
いくつかの考えだが、人々が Next.JS を選ぶ理由と強く関係していると思う
技術的な側面については何とも言えない（Next.js にしか慣れておらず Rails には不慣れなので、この記事が著者の Rails への慣れを反映しているのか、それともより技術的に適したアーキテクチャを反映しているのかは不明だ）。しかし、複数のソフトウェアエンジニアがいる会社が月 1,000 ドル未満のインフラコストを気にするのは奇妙だと思う。ホスティングコストを気にするのは賢明ではない
Rails がもたらしたフロントエンドフレームワークとの相互運用性に対する本当の第一級サポートに注力していれば、今ごろはもっと大きくなっていたはずだ。Hotwire に多大な労力を費やしたが、私は React を使いたいし、他の人たちも自分が慣れているものを使いたいはずだ
Next.js vs. SSR の論争がなぜ起きるのか不思議だ。Next.js はハイブリッドで、かなりうまくやっている。他の SPA フレームワークと対照的に、Next.js は高速な初回ロードのために事前レンダリングされた HTML 出力を生成し、効率的な JS チャンク、リンクにホバーしたときやページレンダリング後にすべての n+1 リンクをプリロードするような設定スイッチ、さらにブレークポイントに応じた効率的な画像の（事前）読み込みも提供する（純粋な SSR ソリューションと比べると、ここはたいていアキレス腱になる）
Rails を少し書いたことはあるが、なぜそこまで熱狂されるのかはよくわからなかった。まったく問題はなかったが、特別なものも見いだせなかった