📖

「React + Rails」と「React on Rails」何がちがうの？

に公開
Rails
React
tech

はじめに

タイトルの質問に答えられますか？
私は答えられませんでした。「React + Rails」と「React on Rails」どちらを使えばいいのか、そもそも違いが何なのか全く分かりませんでした。

私の経験：
個人開発: React + Rails（別々に構築）
業務: React on Rails（gem使用）
業務でReact on Railsに出会ったときは「そんなものがあるのか」程度であり、個人開発でReact + Railsを採用した当時は深く考えておらず「React実際に使いたい」という理由だけで選んでいましたが、本当にこの選択が正しかったのか、両者の違いを深掘りすることにしました。

React + Railsとは

React + Railsは、ReactとRailsを完全に分離して構築する方法です。
構成

my-app/
├── frontend/          # Reactアプリ
│   ├── src/
│   └── package.json
└── backend/           # Railsアプリ（APIモード）
    ├── app/
    └── Gemfile

特徴
完全分離アーキテクチャ

2つの独立したプロジェクト
RailsはAPIモードで作成
別々にデプロイ可能

通信方法

// React側
fetch('http://localhost:3000/api/wines')
  .then(response => response.json())

# ruby Rails側
class Api::WinesController < ApplicationController
  def index
    render json: Wine.all
  end
end

メリット・デメリット

メリット:

完全な独立性（技術選択の自由）
マイクロサービス化しやすい
チーム分担が容易

デメリット:

CORS対応が必要
2つのサーバーを管理
デプロイが2箇所

React on Railsとは

React on Railsは、shakacode社が開発したgemで、RailsアプリにReactを統合します。

構成
my-app/
├── app/
│   ├── controllers/
│   ├── views/          # ERBビュー
│   └── javascript/     # Reactコンポーネント
└── Gemfile            # react_on_rails gem

特徴
統合アーキテクチャ

ReactをRailsビュー内に埋め込む
単一プロジェクトで管理
SSR（サーバーサイドレンダリング）対応

使用例

# コントローラー
def index
  @wines = Wine.all
end

<!-- ビュー -->
<%= react_component("WineList", props: { wines: @wines }) %>

メリット・デメリット

メリット:
セットアップが簡単（1プロジェクト）
SSR標準対応（SEO対策）
Railsの機能をフル活用
1つのサーバーで完結

デメリット:
フロントとバックエンドが密結合
gem依存
大規模化すると管理が複雑

どちらを使うべきか
React + Railsを選ぶ場合
✅ 大規模・長期運用プロジェクト
✅ モバイルアプリも作る予定（APIを使い回す）
✅ 完全なSPA
✅ チームが分かれている

React on Railsを選ぶ場合
✅ 小〜中規模プロジェクト
✅ SEOが重要
✅ 開発スピード重視
✅ 個人開発・スタートアップ

比較表

項目 React + Rails React on Rails
セットアップ 複雑 簡単
開発速度 やや遅い 速い
SSR 自前実装 標準対応
デプロイ 2箇所 1箇所
スケーラビリティ 高い 中程度

まとめ

どちらが優れているわけではなく、プロジェクトの要件次第です。

判断基準:
完全分離が必要 → React + Rails
早く作りたい、SEO重視 → React on Rails
迷ったら → 小規模ならReact on Rails、大規模ならReact + Rails

gemはReact on Rails以外もあるので参考までに
https://qiita.com/kojikojiXX/items/5a9ff3d3d3f315fdf738

Discussion