👺

api について、next.js だと api ディレクトリを作ってその配下につくればいいんじゃないかと思った。

に公開
Next.js
API
Web
Express
ルーティング
tech

ハッカソンに参加した際に一つ疑問に思ったことがあった。

APIのルーティングをapp.tsにまとめているが、next.jsだとAPIディレクトリを作ってその配下につくればいいんじゃないかと思った。

結論：

Next.js だけで完結するなら、app/api/**/route.ts（App Router）や pages/api/*.ts（Pages Router）にAPIルートを置くのが基本です。app.ts にルーティングをまとめるのは、Next.jsとは別のバックエンド（Express / Fastify / Hono など）を立てる設計のときのやり方です。

どっちを選ぶ？判断基準

Next.js の Route Handlers（app/api/.../route.ts）を使うと良いケース

  • フロント（Next）と API を同じアプリで完結させたい
  • デプロイ先も同じ（Vercel / next start 1サービス）
  • CORS を気にしたくない（同一オリジン）
  • 典型的な REST/CRUD 程度で OK
  • Prisma 等の Node ランタイムで動かす（※Edge では不可）

例

// app/api/portfolios/[id]/route.ts
import { prisma } from "@/lib/prisma";

export async function GET(_: Request, { params }: { params: { id: string } }) {
  const data = await prisma.portfolio.findUnique({
    where: { id: Number(params.id) },
    include: { links: true },
  });
  return Response.json(data);
}

export async function POST(req: Request) {
  const body = await req.json();
  const created = await prisma.portfolio.create({ data: body });
  return Response.json(created, { status: 201 });
}

app.ts（Express などの独立したサーバー）にするメリット

  • Next とは独立にスケール/デプロイできる（APIだけ水平スケール、別リージョンなど）
  • 複数クライアント（Next以外：モバイルアプリ/他サービス）から共通で叩く前提
  • 長時間接続/特殊要件：WebSocket、ストリーミング、巨大アップロード、重いバッチ
  • 細かいサーバ制御：CORS/ヘッダ/タイムアウト/ミドルウェアを自由に構成
  • テスト容易：supertest などで E2E テストしやすい
  • APIのバージョニング/ドキュメント（/api/v1、OpenAPI 自動生成 など）を厳密に運用

注意：Next.js の“カスタムサーバー”方式で Express を同一プロセスに組み込むのは非推奨。やるなら Next（フロント）と API サーバーを別プロセス/別サービスにして、LBやリバプロでつなぐのが今の定石です。

デメリット/注意点

方式 デメリット
Next.js の Route Handlers API が Next に密結合（別クライアントや独立スケールがしにくい）／一部サーバーレス特性（起動時間・接続数制限）に留意
別サーバー（app.ts） CORS設定が必要／サービスが増える分インフラ・監視が増える／同一リポジトリでも通信は“外部”扱い

迷ったらこれ

  • Webアプリ1つをサクッと作りたい → Next.js の app/api 一択
  • その API をモバイルや別サービスからも使う・重い処理/WSがある → 別サーバー（app.ts）

Discussion