はじめに

私は新卒1年目のフロントエンドエンジニアです。
フロントエンド開発をしていると、

APIがまだ未完成
仕様は決まっているが実装待ち
画面側の開発を止めたくない

といった状況に直面することがあります。

今回、実際の開発でこの状況に当たり、json-server を使ってモックサーバーを立ち上げることで、API未完成の状態でもフロントエンド開発を進めることができました。

この記事では、

なぜモックサーバーを使うことになったのか
json-server を使って何ができたのか
データが「動的に変わる」モックの便利さ

の3つに焦点を当ててまとめます。

きっかけ

今回作成していたのは、スレッド一覧を管理する画面です。

最初は、フロントエンドの実装を進めるために
以下のようにコード内に固定のダミーデータを書いていました。

dataSource.value = [
  { "id": "1", "title": "スレッド1", "category": "雑談", "author": "作成者", "createdAt": "2024/05/01", "updatedAt": "2024/05/01" },
  { "id": "2", "title": "スレッド2", "category": "音楽", "author": "作成者", "createdAt": "2024/05/01", "updatedAt": "2024/05/01" },
];

この方法で一覧表示までは問題なく作れます。

しかし、開発が進むにつれて次のような不満が出てきました。

追加・編集・削除をしても「本当に通信している感じ」がしない
データが増減したときの挙動が確認しづらい
Network タブでリクエストを確認できない
実際の API ができたときに差分が出そう

以上の点から「実際の API 通信に近い形で動かしたい」と感じるようになりました。

そこで、動的にデータが変わり、
GET / POST / PUT / DELETE を一通り試せる モックサーバー が必要になりました。

モックサーバーを使うことにした理由

モックサーバーがあれば、

バックエンド未完成でもフロント開発を止めずに進められる
実APIと同じように通信処理を書ける
Network タブでリクエスト・レスポンスを確認できる

というメリットがあります。

いくつか選択肢はありましたが、「とにかく手早く立ち上げたい」 という理由から
json-server を使うことにしました。

json-server でモックサーバーを立ち上げる

mock/db.json を作る
まず、モックサーバー用のデータを管理するために
mock ディレクトリを作成し、その中に db.json を用意します。

開発アプリケーション名/
├ mock/
│  └ db.json
├ src/
└ package.jsondb.json

の中身は以下のようにしました。

{
  "threads": [
    {
      "id": "1",
      "title": "スレッド1",
      "category": "雑談",
      "author": "作成者",
      "createdAt": "2024/05/01",
      "updatedAt": "2024/05/01"
    },
    {
      "id": "2",
      "title": "スレッド2",
      "category": "音楽",
      "author": "作成者",
      "createdAt": "2024/05/01",
      "updatedAt": "2024/05/01"
    }
  ]
}

この threads が、そのまま
/threads エンドポイントとして扱われます。

エンドポイントは「このURLにアクセスすると、このデータが操作できる」
という API の入口のようなものです。

json-server では、この入口を自分で定義する必要はなく、
db.json のキー名から自動で作られます。

次にjson-server を起動します。
VS Code のターミナルで、以下のコマンドを実行します。

json-server --watch db.json --port 3000

すると、ターミナルに次のようなログが表示されます。

JSON Server started on PORT :3000
Press CTRL-C to stop
Watching db.json...

( ´ ▽ ` )

Index:
http://localhost:3000/

Endpoints:
http://localhost:3000/threads

ターミナル出力の解説

JSON Server started on PORT :3000
http://localhost:3000 でモックサーバーが起動している
Watching db.json...
db.json をデータソースとして監視しており、データの変更が リアルタイム で反映される
Endpoints: http://localhost:3000/threads
/threads にアクセスするとスレッド一覧が取得できる

GET でデータを取得する
json-server を起動した状態で、ブラウザ、またはフロントエンドから
以下の URL にアクセスすると、db.json に定義した内容を取得できます。

GET http://localhost:3000/threads

mock/db.json に定義した threads が、そのまま JSON 配列として返ってきていることが分かります。

フロントエンドから見ると、通常のAPI通信と同じ

この時点で、フロントエンド側から見ると
json-server は通常のAPIとまったく同じ存在になります。

const res = await fetch("http://localhost:3000/threads");
const data = await res.json();

このコードは、ブラウザに標準で用意されている fetch を使って
/threads という API にリクエストを送り、
返ってきたJSONデータを受け取っているだけのものです。

特別な設定や json-server 専用の書き方は一切ありません。
実際のバックエンド API を呼ぶ場合と、実装の感覚は完全に同じです。

そのため、

開発中は json-server を使う
本番では実際の API に差し替える

といった切り替えもスムーズに行えます。

「今はモックサーバーを使っている」ということを
意識せずに開発できる点が、 json-serverの大きな魅力 です。

POST / PUT / DELETE を使ってみる

〜データが「動く」モックサーバーを体感する〜

json-server の大きな特徴は、
REST API として自然にふるまってくれる点です。

REST APIとは

REST API とは、 HTTP メソッド（GET / POST / PUT / DELETE）を使ってデータの取得・追加・更新・削除を行う API の設計方法を指します。

それぞれのメソッドには役割があり、

GET：データを取得する
POST：データを追加する
PUT：データを更新する
DELETE：データを削除する

といった形で使い分けられます。

フロントエンド開発では、このルールに沿って API を呼び分けるのが一般的ですが、
json-server はこれを特別な設定なしで再現してくれます。

POST（追加）

新しいスレッドを追加すると、

自動で id が付与される
db.json にデータが追記される
Network タブで POST リクエストが確認できる

という動きをします。

「 id：e2a6 」と自動でidが割り振られているのが分かります。
また、画面操作・API通信・データ更新が連動しているのを直感的に確認できます。

実際の画面

db.json（POST）

{
  "threads": [
    {
      "id": "1",
      "title": "スレッド1",
      "category": "雑談",
      "author": "作成者",
      "createdAt": "2024/05/01",
      "updatedAt": "2024/05/01"
    },
    {
      "id": "2",
      "title": "スレッド2",
      "category": "音楽",
      "author": "作成者",
      "createdAt": "2024/05/01",
      "updatedAt": "2024/05/01"
    },
    {
      "id": "e2a6",
      "title": "新規スレッド",
      "category": "その他",
      "author": "著者",
      "createdAt": "2026/02/13",
      "updatedAt": "2026/02/13"
    }
  ]
}

PUT（更新）

指定した id のスレッドを更新できます。

編集操作で PUT リクエストが発生
db.json の該当データが上書きされる

「 id：e2a6 」の「新規スレッド」を「新規スレッド_改」と変更されており、動的にdb.jsonが変更されていることが分かります。
また、「更新＝PUT」という対応関係を、実際の通信を見ながら理解できます。

実際の画面

db.json（PUT）

{
  "threads": [
    {
      "id": "1",
      "title": "スレッド1",
      "category": "雑談",
      "author": "作成者",
      "createdAt": "2024/05/01",
      "updatedAt": "2024/05/01"
    },
    {
      "id": "2",
      "title": "スレッド2",
      "category": "音楽",
      "author": "作成者",
      "createdAt": "2024/05/01",
      "updatedAt": "2024/05/01"
    },
    {
      "id": "e2a6",
      "title": "新規スレッド_改",
      "category": "その他",
      "author": "著者",
      "createdAt": "2026/02/13",
      "updatedAt": "2026/02/13"
    }
  ]
}

DELETE（削除）

指定したスレッドを削除すると、

画面からデータが消える
db.json からも削除される
DELETE リクエストが Network タブに表示される

「 id：1 」のスレッドが削除され、db.jsonも変更されていることが分かります。
削除処理まで含めて、実際の API と同じ感覚で試せるのが特徴です。

実際の画面

db.json（DELETE）

{
  "threads": [
    {
      "id": "2",
      "title": "スレッド2",
      "category": "音楽",
      "author": "作成者",
      "createdAt": "2024/05/01",
      "updatedAt": "2024/05/01"
    },
    {
      "id": "e2a6",
      "title": "新規スレッド_改",
      "category": "その他",
      "author": "著者",
      "createdAt": "2026/02/13",
      "updatedAt": "2026/02/13"
    }
  ]
}

動的に変わるモックが便利だった点は以下の通りです。

固定データでは確認できない挙動を試せる
実APIとほぼ同じ感覚で実装できる
Networkタブで通信内容を確認できる
バックエンド実装前に不具合に気づける

かなり本番に近い開発体験をすることがでいると感じました。

まとめ

json-server を使えば、API未完成でもフロント開発を進められる
db.json を用意するだけで REST API が完成する
GET だけでなく、POST / PUT / DELETE も試せる
データが動的に変わるため、実践的な検証ができる

おわりに

今回、json-server を使ってモックサーバーを立てたことで、
バックエンドの実装を待たずにフロントエンド開発を進めることができました。

APIが未完成な段階でも、

画面実装
非同期通信
データ更新の挙動確認

まで一通り進められるのは、大きなメリットだと感じています。
同じような状況の方の参考になれば幸いです。