今回の記事では、ReactとRails APIを用いて投稿サービスを作成します。
フロントエンドにはReactを使用したSPA、バックエンドにはRails APIを構築し、ブラウザでアプリケーションを表示します。
この記事を読むポイント
この記事では、ReactとRails APIを用いた投稿サービスの開発全体の流れを解説します。
記事の分量が多くなったため、環境構築や実装などの詳細な手順は、それぞれ別の記事で解説しています。
まずはこの記事で開発全体の流れを把握し、その後、必要に応じて各記事を読み進めるのがおすすめです。
読者の方のレベルに応じて、以下のような読み方がおすすめです。
- 開発の流れをしっかり理解したい方:「1. 要件定義を行う」から順番に読み進める
- すぐに実装を始めたい方:「6. 開発環境の準備」から読み進める
1. 要件定義を行う(何を作るか決める)
まずは作りたいサービスを決めましょう。
今回は、掲示板のような「投稿サービス」を作成します。
機能要件とは、アプリケーションの「具体的な機能」に関する仕様のことです。
今回は、以下の要件に沿って実装を進めていきます。
- 投稿の作成:タイトル・本文・作成者名を入力して投稿を作成できる
- 投稿の一覧表示:作成された投稿を一覧で確認できる
- 投稿の詳細表示:投稿の詳細を確認できる
- 投稿の編集:作成された投稿を編集できる
- 投稿の削除:作成された投稿を削除できる
- 認証機能なし:誰でも投稿の作成・編集・削除を行える
非機能要件とは、パフォーマンスやセキュリティ、拡張性、可用性など、システムの品質に関する要件のことです。
今回は詳細な非機能要件は定義せず、まずはサービスを完成させることを目指します!
実務では、Figma等を使用して、作成するサービスの画面設計(デザイン)を行います。
今回はほとんどデザインを必要としないため、画面設計は行いません。
2. アーキテクチャ設計を行う(どのような構成で作るか決める)
今回は以下の2つのアーキテクチャを採用します。
- ヘッドレスアーキテクチャ(フロントエンドとバックエンドを分けて開発)
- Web APIアーキテクチャ(バックエンドをAPIとして開発)
ヘッドレスアーキテクチャとは、フロントエンドとバックエンドを分離して開発するアーキテクチャです。
Web APIアーキテクチャとは、バックエンドをAPIとして開発するアーキテクチャです。
今回採用するアーキテクチャの全体構成は、以下の通りです。

※ モノリシックアーキテクチャを採用する場合は、フロントエンドとバックエンドを1つのアプリケーションとして構築します。
※ ここでは、それぞれのアーキテクチャの特徴をざっくり理解できれば大丈夫です。まずは実際に作りながら理解していきましょう。
3. DB設計を行う(データをどう保存するか決める)
投稿サービスのデータを格納するために、データベースの設計を行います。
今回は投稿用のテーブルのみを作成するため、比較的シンプルな設計になります。
ここでは、投稿データの構造を以下の図に整理します。

※ Ruby on Railsでは、idが自動的に主キーとして設定されます。また、created_atとupdated_atも自動的に追加されるため、図では省略しています。
4. API設計を行う(データをどう操作するか決める)
投稿データの取得・作成・編集・削除を行うためのAPIを設計します。
今回は、投稿機能に必要なAPIのHTTPメソッドとエンドポイントを以下のように定義します。
| HTTPメソッド | エンドポイント | 処理 |
|---|---|---|
| GET | /posts | 投稿一覧を取得する |
| POST | /posts | 投稿を作成する |
| GET | /posts/:id | 投稿詳細を取得する |
| PUT | /posts/:id | 投稿を編集する |
| DELETE | /posts/:id | 投稿を削除する |
実際の開発では、OpenAPIなどを使用して、エンドポイントだけでなく、リクエストやレスポンスの形式、ステータスコードなどのAPI仕様を定義することもあります(Swagger Editorなどのツールを使用して、API仕様書を作成・確認できます)。
今回はシンプルな投稿サービスのため、API仕様書は作成せず、必要なHTTPメソッドとエンドポイントのみを定義して実装を進めます。
5. フロントエンド設計を行う(ユーザーの操作方法やコードの構成を決める)
Reactで画面を作成する前に、ユーザーがどのように画面を操作するのか、コードをどのような構成にするのかを決めます。
今回は、以下の3つについて考えます。
- ユーザーフロー
- フォルダ構成
- 状態管理
※ 今回はシンプルな投稿サービスを作成するため、スタイリングは行いません。実際の開発では、CSS ModulesやCSS-in-JSなど、さまざまな方法でスタイルを適用します。
※ また、コンポーネント設計、バリデーション、エラーハンドリングなどの詳細な設計についても、今回は扱いません。
ユーザーフローとは、ユーザーがアプリケーションをどのような流れで操作するのかを整理したものです。
今回は、投稿の作成・一覧表示・詳細表示・編集・削除について、以下の流れで操作できるようにします。
新規投稿の作成
- 「投稿作成」ボタンをクリックする
- 投稿のタイトル・内容・作成者名を入力する
- 「作成」ボタンをクリックする
- 投稿が作成され、投稿一覧に表示される
投稿一覧の確認
- 投稿一覧ページにアクセスする
- 作成された投稿が一覧で表示される
投稿詳細の確認
- 投稿一覧から確認したい投稿を選択する
- 投稿詳細ページが表示される
- 投稿のタイトル・内容・作成者名を確認する
投稿の編集
- 投稿一覧から編集したい投稿を選択する
- 「編集」ボタンをクリックする
- タイトル・内容・作成者名を編集する
- 「更新」ボタンをクリックする
- 更新された投稿を確認する
投稿の削除
- 投稿一覧から削除したい投稿を選択する
- 「削除」ボタンをクリックする
- 投稿が削除され、投稿一覧から表示されなくなったことを確認する
今回は、srcフォルダの直下を以下のように分けます。
infra/:API通信に関する処理を格納するpages/:ページ単位のコンポーネントを機能ごとに格納するcomponents/:複数の画面で利用できる共通コンポーネントを格納する
投稿機能に関するページは、pages/posts/の中にまとめて作成します。
このように機能ごとにフォルダを分けることで、ファイルの役割や配置場所が分かりやすくなります。
※ 今回は共通コンポーネントを作成しないため、components/は使用しません。
状態管理とは、「画面に表示するデータや、ユーザーの操作によって変化する値」を管理することです。
今回はシンプルな投稿サービスのため、ReactのuseStateを使用し、各ページのコンポーネント内で状態を管理します。また、APIからのデータ取得などにはuseEffectを使用します。
※ 状態管理やデータ取得などの処理は、必要に応じてカスタムHooksなどに分離する方法もあります。
6. 開発環境の準備
それでは、React、Rails API、PostgreSQLを使用した開発環境を構築していきます。
今回は、Docker・Docker Composeを使用して環境構築を行います。
Dockerで何ができるのかや、使用するメリットについては、「Dockerとは|できること・メリット・使い方」を参考にしてください。
Docker Composeで何ができるのかや、使用するメリットについては、「Docker Composeとは|できること・メリット・使い方」を参考にしてください。
それでは、開発環境を準備していきます。
以下の記事を参考に、React、Rails API、PostgreSQLの開発環境を構築してください。
※ データベースにMySQLを使用したい方は、「Docker ComposeでRails APIとMySQLの環境構築をする方法」を参考にしてください。
7. 投稿機能を作る
ここまでで、投稿サービスを作成するための設計と開発環境の準備ができました。
それでは、実際にReactとRails APIを使用して投稿機能を実装していきます。
投稿機能の作成方法は、「【実装編】ReactとRails APIで投稿サービスを作る(認証なし)」で詳しく解説しています。
終わりに
この記事では、ReactとRails APIを用いた投稿サービスの開発手順を紹介しました。
実際の開発では、コーディングだけでなく、要件定義や設計、エラー調査などにも多くの時間を使います。
まずは小さなアプリケーションを完成させ、徐々により実践的な開発へステップアップしていきましょう。

