Railsとフロントエンドのディレクトリ構成：モダンな開発環境の設計📁

はじめに (対象読者・この記事でわかること)

この記事は、Ruby on Railsを使用したバックエンド開発に慣れているが、ReactやVue.js、AngularなどのJavaScriptフレームワークを組み合わせたフロントエンド開発を始めたい方を対象としています。特に、複数の技術を組み合わせた際にどのようにプロジェクトを構成すれば良いか迷っている初心者から中級者向けの内容です。

この記事を読むことで、RailsとJavaScriptフレームワークを組み合わせた際の効果的なディレクトリ構成の選択肢、各構成のメリット・デメリット、実際の実装方法が理解できます。また、プロジェクトの規模やチーム体制に応じた最適な構成の判断基準も学べるようになります。最近ではSPA（シングルページアプリケーション）やSSR（サーバーサイドレンダリング）など様々なアーキテクチャが登場しており、適切なディレクトリ構成は開発効率や保守性に直結します。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。

前提となる知識1: Ruby on Railsの基本的な知識（MVC構造、ルーティング、ジェネレータなど） 前提となる知識2: JavaScriptおよびnpm/yarnの基本的な知識（パッケージ管理、ビルドツールなど） 前提となる知識3: HTML/CSSの基本的な知識

Railsとフロントエンド連携の現状と課題

近年のWeb開発では、バックエンドとフロントエンドの分離が一般的になっています。Ruby on Railsは当初からビューテンプレートエンジンとしてERBを提供していましたが、昨今の複雑なUIや動的なコンポーネントを扱うにはJavaScriptフレームワークと連携する必要があります。

このような状況で開発者が直面する課題はいくつかあります。第一に、どのようにプロジェクトを構成すれば開発効率が最大化されるか、第二に、本番環境でのデプロイプロセスをどのように設計すれば良いか、そして第三に、チーム内での開発分担をどのように行えば良いか、といった点です。

特にディレクトリ構成は、これらの課題を解決する上で非常に重要な要素です。適切な構成を選ぶことで、以下のようなメリットが期待できます。

1. 開発効率の向上: 開発者が関連するファイルをすぐに見つけられるようになり、コードの変更が容易になります
2. 保守性の向上: コードの責任範囲が明確になり、将来的な機能追加や修正がスムーズになります
3. チーム開発の円滑化: 新しいメンバーがプロジェクトに参加しやすくなり、チーム全体の生産性が向上します
4. CI/CDプロセスの最適化: ビルドやテストの自動化がしやすくなり、継続的インテグレーションが実現しやすくなります

一方で、不適切な構成は開発のボトルネックとなり、プロジェクトの遅延や品質低下を引き起こす可能性もあります。そこで、次のセクションでは具体的なディレクトリ構成のパターンとその実装方法について詳しく解説します。

ディレクトリ構成の具体的なパターンと実装方法

Railsアプリケーションとフロントエンドフレームワークを組み合わせる場合、主に以下の3つのディレクトリ構成パターンが考えられます。

1. モノリポジトリ構成: Railsとフロントエンドを単一のリポジトリで管理
2. マルチリポジトリ構成: バックエンドとフロントエンドを別々のリポジトリで管理
3. Railsエンジン構成: フロントエンドをRailsエンジンとして実装

それぞれの構成について、特徴や実装方法、メリット・デメリットを解説します。

モノリポジトリ構成

モノリポジトリ構成は、Railsアプリケーションとフロントエンドのソースコードを単一のリポジトリで管理するアプローチです。近年の大規模なWebアプリケーション開発で採用されることが多い構成です。

ディレクトリ構成例

my_app/
├── backend/
│   ├── app/
│   ├── bin/
│   ├── config/
│   ├── db/
│   ├── lib/
│   ├── log/
│   ├── public/
│   ├── test/
│   └── Gemfile
├── frontend/
│   ├── public/
│   ├── src/
│   ├── .babelrc
│   ├── .eslintrc
│   ├── .postcssrc
│   ├── package.json
│   └── webpack.config.js
└── docker-compose.yml

実装手順

ステップ1: プロジェクトの初期化

まず、Railsアプリケーションとフロントエンドプロジェクトをそれぞれ作成します。

Bash

# Railsアプリケーションの作成
rails new backend --api --database=postgresql

# フロントエンドプロジェクトの作成 (例: React)
npx create-react-app frontend

ステップ2: 共通設定の追加

プロジェクトルートにdocker-compose.ymlなどの共通設定ファイルを配置します。

Yaml

# docker-compose.yml
version: '3'
services:
  backend:
    build: ./backend
    ports:
      - "3000:3000"
    volumes:
      - ./backend:/app
    environment:
      - DATABASE_PASSWORD=password
      - RAILS_ENV=development
  frontend:
    build: ./frontend
    ports:
      - "8080:8080"
    volumes:
      - ./frontend:/app
      - /app/node_modules
    environment:
      - NODE_ENV=development
    depends_on:
      - backend

ステップ3: 開発用のスクリプト設定

package.jsonに開発用のスクリプトを追加します。

Json

// ルートディレクトリのpackage.json
{
  "name": "my-app",
  "version": "1.0.0",
  "scripts": {
    "dev": "concurrently \"npm run dev:backend\" \"npm run dev:frontend\"",
    "dev:backend": "cd backend && rails s",
    "dev:frontend": "cd frontend && npm start",
    "build": "cd frontend && npm run build",
    "install:all": "npm install && cd backend && bundle install && cd ../frontend && npm install"
  },
  "devDependencies": {
    "concurrently": "^5.3.0"
  }
}

ステップ4: API連携の設定

Rails側でCORS設定を行い、フロントエンドからAPIにアクセスできるようにします。

Ruby

# backend/config/application.rb
module Backend
  class Application < Rails::Application
    config.middleware.insert_before 0, Rack::Cors do
      allow do
        origins 'http://localhost:8080'
        resource '*',
          headers: :any,
          methods: [:get, :post, :put, :patch, :delete, :options, :head],
          credentials: true
      end
    end
  end
end

メリットとデメリット

メリット: - 共通設定の管理が容易（CI/CD、Docker設定など） - バージョンの一貫性が保たれやすい - リポジトリ間の依存関係が明確 - ファイルの移動やリファクタリングが容易

デメリット: - リポジトリが肥大化しやすい - ビルド時間が長くなる可能性 - 開発環境のセットアップが複雑になる場合がある - フロントエンドとバックエンドの開発サイクルが密結合になる

適したケース

• 中小規模〜大規模のアプリケーション
• フロントエンドとバックエンドが密接に連携する必要がある場合
• チームが共同で開発している場合

マルチリポジトリ構成

マルチリポジトリ構成は、Railsアプリケーション（バックエンド）とフロントエンドをそれぞれ独立したリポジトリで管理するアプローチです。伝統的なWeb開発のアプローチですが、マイクロサービスアーキテクチャと相性が良い構成です。

ディレクトリ構成例

# backendリポジトリ
backend/
├── app/
├── bin/
├── config/
├── db/
├── lib/
├── log/
├── public/
├── test/
└── Gemfile

# frontendリポジトリ
frontend/
├── public/
├── src/
├── .babelrc
├── .eslintrc
├── .postcssrc
├── package.json
└── webpack.config.js

実装手順

ステップ1: 独立したリポジトリの作成

Railsアプリケーションとフロントエンドプロジェクトをそれぞれ独立したリポジトリとして作成します。

Bash

# バックエンドリポジトリの作成
mkdir backend
cd backend
rails new . --api --database=postgresql
git init
git add .
git commit -m "Initial commit"

# フロントエンドリポジトリの作成
cd ..
mkdir frontend
cd frontend
npx create-react-app .
git init
git add .
git commit -m "Initial commit"

ステップ2: APIエンドポイントの定義

バックエンド側でAPIエンドポイントを定義し、フロントエンドからアクセスできるようにします。

Ruby

# backend/app/controllers/api/v1/users_controller.rb
class Api::V1::UsersController < ApplicationController
  before_action :set_user, only: [:show, :update, :destroy]

  def index
    @users = User.all
    render json: @users
  end

  def show
    render json: @user
  end

  # ... 他のアクション
end

ステップ3: 環境変数の設定

フロントエンド側で環境変数を使用してAPIのベースURLを設定します。

Javascript

// frontend/src/config/api.js
const API_BASE_URL = process.env.REACT_APP_API_BASE_URL || 'http://localhost:3000/api/v1';

export const getUsers = () => {
  return fetch(`${API_BASE_URL}/users`)
    .then(response => response.json());
};

// ... 他のAPI関数

ステップ4: CI/CDパイプラインの設定

それぞれのリポジトリにCI/CDパイプラインを設定します。

Yaml

# backend/.github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-ruby@v1
        with:
          ruby-version: '2.7'
      - run: bundle install
      - run: bundle exec rspec

Yaml

# frontend/.github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '14'
      - run: npm install
      - run: npm run test
      - run: npm run build

メリットとデメリット

メリット: - リポジトリが小さく管理しやすい - 各チームが独立した開発サイクルを持てる - 特定の技術スタックに特化した開発が可能 - セキュリティ上のリスクが分散される

デメリット: - 共通設定の管理が複雑になる - バージョン管理が煩雑になる - リポジトリ間の依存関係の追跡が難しい - 開発環境のセットアップが手間

適したケース

• 大規模なアプリケーションで独立したチームが開発している場合
• マイクロサービスアーキテクチャを採用している場合
• フロントエンドとバックエンドの更新頻度が大きく異なる場合

Railsエンジン構成

Railsエンジン構成は、フロントエンドをRailsエンジンとして実装するアプローチです。Railsの機能を最大限に活用し、バックエンドとフロントエンドを密接に連携させたい場合に有効です。

ディレクトリ構成例

my_app/
├── app/
│   ├── controllers/
│   ├── models/
│   ├── views/
│   └── frontend/
│       ├── app/
│       ├── assets/
│       ├── package.json
│       └── webpack.config.js
├── config/
├── db/
├── lib/
├── public/
├── test/
└── Gemfile

実装手順

ステップ1: Railsエンジンの作成

Railsアプリケーション内にエンジンを作成します。

Bash

rails plugin new frontend_engine --mountable

ステップ2: フロントエンドフレームワークの導入

エンジン内にフロントエンドフレームワークを導入します。

Bash

cd frontend_engine
npm init -y
npm install react react-dom webpack webpack-cli babel-loader @babel/core @babel/preset-env @babel/preset-react --save-dev

ステップ3: Webpackerの設定

RailsのWebpacker gemを使用して、フロントエンドのビルドを設定します。

Ruby

# Gemfileに追加
gem 'webpacker', '~> 5.0'
gem 'react-rails', '~> 2.6'

Bash

bundle install
bundle exec rails webpacker:install
bundle exec rails webpacker:install:react

ステップ4: コンポーネントの実装

Reactコンポーネントを実装し、Railsビューで呼び出します。

Javascript

// frontend_engine/app/frontend/components/UserList.jsx
import React, { useState, useEffect } from 'react';
import axios from 'axios';

const UserList = () => {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    axios.get('/api/v1/users')
      .then(response => {
        setUsers(response.data);
      })
      .catch(error => {
        console.error('Error fetching users:', error);
      });
  }, []);

  return (
    <div>
      <h2>Users</h2>
      <ul>
        {users.map(user => (
          <li key={user.id}>{user.name}</li>
        ))}
      </ul>
    </div>
  );
};

export default UserList;

Erb

<!-- frontend_engine/app/views/frontend_engine/index.html.erb -->
<%= react_component('UserList', {}, { prerender: true }) %>

ステップ5: エンジンのマウント

エンジンをRailsアプリケーションにマウントします。

Ruby

# config/routes.rb
Rails.application.routes.draw do
  mount FrontendEngine::Engine => "/frontend", as: "frontend_engine"

  # ... 他のルート
end

メリットとデメリット

メリット: - Railsの全機能をフロントエンドから利用可能 - セッション管理や認証が容易 - 共通の設定やヘルパーが利用できる - 開発環境のセットアップが比較的簡単

デメリット: - Railsに依存した構成になる - フロントエンドのビルドプロセスが複雑になる - 大規模なフロントエンド開発には不向きな場合がある - Railsのアップグレード時に影響を受けやすい

適したケース

• 中小規模のアプリケーション
• Railsの機能をフロントエンドから活用したい場合
• 単一のチームで開発を行う場合
• SSR（サーバーサイドレンダリング）が必要な場合

実装上のハマりポイントと解決策

ハマった点1: CORSエラー

問題: フロントエンドからRails APIにアクセスしようとすると、CORS（オリジン間リソース共有）エラーが発生する。

解決策: Rails側でCORS設定を行います。

Ruby

# config/application.rb
module YourApp
  class Application < Rails::Application
    config.middleware.insert_before 0, Rack::Cors do
      allow do
        origins 'http://localhost:3000', 'http://localhost:8080'
        resource '*',
          headers: :any,
          methods: [:get, :post, :put, :patch, :delete, :options, :head],
          credentials: true
      end
    end
  end
end

ハマった点2: 環境変数の共有

問題: 開発環境と本番環境でAPIのベースURLを切り替えたいが、環境変数が正しく共有されない。

解決策: dotenv-rails gemを使用して環境変数を管理します。

Ruby

# Gemfileに追加
gem 'dotenv-rails', groups: [:development, :test]

Bash

# .envファイルの作成
echo "API_BASE_URL=http://localhost:3000/api/v1" >> .env

Javascript

// frontend/src/config/api.js
require('dotenv').config();

const API_BASE_URL = process.env.API_BASE_URL || 'http://localhost:3000/api/v1';

ハマった点3: アセットパイプラインの競合

問題: RailsのアセットパイプラインとWebpackのビルド結果が競合し、意図しないファイルが提供される。

解決策: Railsのアセットパイプラインを無効にするか、Webpackの出力先を変更します。

Ruby

# config/environments/development.rb
config.assets.enabled = false

Javascript

// webpack.config.js
module.exports = {
  // ... 他の設定
  output: {
    path: path.resolve(__dirname, 'app/frontend/dist'),
    filename: 'bundle.js'
  }
};

まとめ

本記事では、Railsとフrontエンドフレームワークを組み合わせた際のディレクトリ構成のパターンと実装方法について解説しました。

• モノリポジトリ構成: 単一のリポジトリで管理し、共通設定の管理が容易。密接な連携が必要な場合に適している。
• マルチリポジトリ構成: 独立したリポジトリで管理し、チームや開発サイクルの分離がしやすい。大規模なアプリケーションやマイクロサービスに適している。
• Railsエンジン構成: フロントエンドをRailsエンジンとして実装し、Railsの機能を最大限に活用できる。中小規模のアプリケーションやSSRが必要な場合に適している。

この記事を通して、プロジェクトの規模や要件に応じた最適なディレクトリ構成の選択方法が理解できたことと思います。適切な構成を選ぶことで、開発効率の向上や保守性の改善が期待できます。

今後は、選択した構成に基づいた具体的な開発フローや、CI/CDパイプラインの最適化についても記事にする予定です。

参考資料

参考にした記事、ドキュメント、書籍などがあれば、必ず記載しましょう。

• Rails Guides: Engines
• Webpacker Documentation
• React on Rails Documentation
• Monorepos vs Multirepos: A Comprehensive Guide
• Setting up Rails with React: A Step-by-Step Guide