Fastify を1年運用してわかった Express との違い
Node.jsのWebフレームワーク選定で迷っている個人開発者へ、1年運用の実感を残す
あなたがNode.jsでWebサーバーを書くとき、ExpressとFastifyのどちらを選ぶべきか悩んだことがあるはずです。私はGramShift Web側 (gramshift.com、Stripe webhook受信、Heartbeat受信、ダッシュボード API) を、最初Expressで作り、後にFastifyに移行しました。1年運用してわかった具体的な違いと、Fastifyに移行して得たメリットを共有します。
当初Expressで作った理由とその限界
GramShift Web側の初期実装はExpressでした。理由は単純で、Node.jsエコシステムで最も普及しているフレームワークだったからです。情報量が大きく多く、ChatGPTに質問しても的確な回答が返ってくる、ライブラリの組み合わせも豊富です。
しかし、運用4-5ヶ月目に2つの不満が出てきました。第一に、リクエストのバリデーションを手動で書く工数が多い。typebox やJoi等で補強していましたが、ルートごとに記述が増えて煩雑になります。第二に、エラーハンドリングが try-catch まみれになり、コードの見通しが悪い。これらの不満が積み重なり、Fastify への移行を検討するきっかけになりました。
Fastify に移行して得た3つのメリット
Express から Fastify に移行して、明確に良くなったのは以下の3点です。
- JSON Schema validation 内蔵: ルート定義に schema を書くだけで、リクエストボディの型チェックを自動化できる
- パフォーマンス向上: ベンチマークで Express の約 2-3倍の RPS が出る、私のケースでも実測で 1.5倍程度の改善
- エラーハンドリングが宣言的: setErrorHandler() で集中管理、try-catch の散乱がなくなる
とくに JSON Schema validation のメリットは大きく、API バグの大幅減少につながりました。Express では「リクエストボディの ユーザーID が undefined だった」のようなエラーが本番でちらほら出ていましたが、Fastify移行後はゼロになりました。
具体的な書き方の差
同じエンドポイントを Express と Fastify で書き比べると、Fastify のシンプルさが明確に分かります。
// Express の場合
app.post('/api/users', async (req, res) => {
if (!req.body.email || !req.body.password) {
return res.status(400).send({ error: 'Missing required fields' });
}
try {
const user = await createUser(req.body);
res.send(user);
} catch (e) {
res.status(500).send({ error: e.message });
}
});
// Fastify の場合
fastify.post('/api/users', {
schema: {
body: {
type: 'object',
required: ['email', 'password'],
properties: {
email: { type: 'string', format: 'email' },
password: { type: 'string', minLength: 8 }
}
}
}
}, async (req) => {
return await createUser(req.body); // バリデーション自動、エラーは setErrorHandler で集中処理
});Fastify の書き方は、API ドキュメントとしての可読性も高く、後から読み返しても意図がすぐ伝わります。schema を一度書けば Swagger 自動生成も可能なので、API ドキュメントを別途書く手間も省けます。
Express から Fastify への移行コスト
Express から Fastify への移行は、コードの大半を書き直す必要があります。私のケースでは、約 15エンドポイントを移行するのに丸2日かかりました。具体的にはミドルウェア (CORS、認証、ロギング) の書き換えに半日、ルート定義の書き換えに1日、エラーハンドリングの集中化に半日、という配分です。
移行作業中は、Express版と Fastify版を並行運用しました。リバースプロキシ (nginx) で一部のエンドポイントだけ Fastify版に振り、徐々に切替える形です。これで「移行中にサービスが止まる」リスクをゼロにできました。
個人開発SaaSで Fastify を選ぶべき条件
個人開発SaaSで Fastify を選ぶべき条件は、以下のパターンです。
- API中心の構成 (フロントは別途)、JSON API を多用する
- リクエスト/レスポンスの型安全性を重視する
- パフォーマンスがクリティカル (1秒間に数百リクエスト以上)
- OpenAPI/Swagger ドキュメントを自動生成したい
逆に、シンプルな CRUD だけ、エコシステム重視、既存の Express コードベースが大量にある、という場合は Express のままで問題ありません。フレームワーク選択は技術的判断であると同時に、運用コストと開発体験の判断でもあります。