Express vs Fastify vs Hapi vs Koa：実務で選ぶべきサーバーフレームワーク

Node.js でサーバーサイドを構築する際、express、fastify、hapi、koa の 4 つが主要な選択肢となります。フロントエンド開発者が BFF や API サーバーを担う場合、これらの違いを理解することは重要です。単に「速い」「遅い」だけでなく、コードの書き方、エラー処理、そしてメンテナンス性に大きな違いがあります。

🚀 サーバー起動と基本構造

各フレームワークは、サーバーの立ち上げ方とリクエストの受け付け方に違いがあります。

express は最もシンプルで、関数ベースのミドルウェアを使います。

// express: 基本サーバー
const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello Express');
});

app.listen(3000);

fastify はインスタンスを作成し、スキーマ定義を容易にします。

// fastify: 基本サーバー
const fastify = require('fastify')({ logger: true });

fastify.get('/', async (request, reply) => {
  return { hello: 'Hello Fastify' };
});

fastify.listen({ port: 3000 });

hapi は設定オブジェクトを通じてサーバーを定義します。

// hapi: 基本サーバー
const Hapi = require('@hapi/hapi');

const init = async () => {
  const server = Hapi.server({ port: 3000, host: 'localhost' });
  
  server.route({
    method: 'GET',
    path: '/',
    handler: (request, h) => {
      return 'Hello Hapi';
    }
  });

  await server.start();
};

koa は非同期関数を核心に置き、ctx オブジェクトを使います。

// koa: 基本サーバー
const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.body = 'Hello Koa';
});

app.listen(3000);

🧩 ミドルウェアとコンテキスト処理

リクエストとレスポンスをどう扱うかは、開発体験に直結します。

express は req と res オブジェクトを直接操作します。ミドルウェアは next() を呼び出して制御します。

// express: ミドルウェア
app.use((req, res, next) => {
  console.log(req.url);
  next();
});

fastify は request と reply を使います。エンコーディングやシリアライズが自動最適化されます。

// fastify: ミドルウェア
fastify.addHook('preHandler', async (request, reply) => {
  console.log(request.url);
});

hapi は request と h (h toolkit) を使います。拡張性が高いですが、記述量が増えます。

// hapi: ミドルウェア（拡張機能）
server.ext('onRequest', (request, h) => {
  console.log(request.path);
  return h.continue;
});

koa は単一の ctx オブジェクトに全てを集約します。非同期フローが自然に書けます。

// koa: ミドルウェア
app.use(async (ctx, next) => {
  console.log(ctx.url);
  await next();
});

✅ 入力検証（バリデーション）

API 開発において、入力データの検証は必須です。ここで大きな差が出ます。

express は標準で検証機能を持ちません。joi や zod などのライブラリを自分で組み込む必要があります。

// express: 手動検証が必要
app.post('/user', (req, res) => {
  if (!req.body.email) {
    return res.status(400).send('Email required');
  }
  // 処理...
});

fastify は JSON Schema ベースの検証がビルトインされています。設定するだけで自動検証されます。

// fastify: スキーマ検証
fastify.post('/user', {
  schema: {
    body: {
      type: 'object',
      required: ['email'],
      properties: { email: { type: 'string' } }
    }
  }
}, async (request, reply) => {
  return { status: 'ok' }; // 検証失敗時は自動エラー
});

hapi も joi をベースとした強力な検証機能を持っています。

// hapi: 検証ルール
server.route({
  method: 'POST',
  path: '/user',
  options: {
    validate: {
      payload: { email: Joi.string().required() }
    }
  },
  handler: (request, h) => ({ status: 'ok' })
});

koa は Express と同様、検証ライブラリの追加が必要です。

// koa: 手動検証が必要
app.use(async ctx => {
  if (!ctx.request.body.email) {
    ctx.status = 400;
    ctx.body = 'Email required';
    return;
  }
});

⚠️ エラー処理の仕組み

予期せぬエラーをどうキャッチするかは、システムの安定性に影響します。

express は next(err) を使ってエラーを伝播させ、専用のエラーハンドラミドルウェアで受けます。

// express: エラーハンドリング
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).send('Something broke!');
});

fastify は try/catch または専用のエラーハンドラフックを使います。

// fastify: エラーハンドリング
fastify.setErrorHandler((error, request, reply) => {
  reply.status(500).send({ error: error.message });
});

hapi は boom などのツールを使い、レスポンスオブジェクトでエラーを表現します。

// hapi: エラーハンドリング
handler: (request, h) => {
  throw Boom.badImplementation('Server error');
}

koa は try/catch をミドルウェア内で明示的に書くか、アプリレベルのイベントで受けます。

// koa: エラーハンドリング
app.on('error', err => {
  console.error('app error', err);
});

📊 比較サマリー

💡 結論と推奨

express は、迷ったときの安全策です。ドキュメントやサードパーティ製ミドルウェアが圧倒的に多く、フロントエンド開発者がサーバーサイドに初めて触れる場合にも最適です。ただし、性能最適化や検証ロジックは自分で組む必要があります。

fastify は、現代の API 開発において最もバランスが取れています。検証機能が含まれているため、コード量が減り、パフォーマンスも優れています。新規プロジェクトで迷ったら、まず fastify を検討する価値があります。

hapi は、設定による制御を好む大規模システムで依然として使われています。しかし、コミュニティの活動は以前より落ち着いているため、新規採用には慎重になるべきです。

koa は、Express のモダンな後継として作られましたが、フル機能フレームワークというよりはライブラリに近いです。独自のミドルウェア構造を理解できる上級者向けです。

最終的には、チームの習熟度とプロジェクトの規模で決まります。性能と開発効率を両立したいなら fastify、既存資産や情報量を重視するなら express が妥当な選択でしょう — どちらを選んでも、Node.js のエコシステム内で十分なサポートが得られます。