@maru
Fastify 5アーキテクチャ — なぜEdgeではなくNode.jsに集中したのか
Fastify 5は、エッジやサーバーレスランタイムへと向かう最近のフレームワークのトレンドとは対照的に、Node.jsバックエンドの高性能化という本質的な価値に集中する王道を選択しました。サポートエンジンをNode.js 20バージョン以上に明確に制限し、古い減価償却APIやアーキテクチャの負債を大胆に削減しました。
サーバーレスの軽快さの代わりに、強力なプラグイン分離アーキテクチャとスキーマベースのコンパイル性能を最大化する賢い路線を選択した結果です。大規模なトラフィックを処理するコンテナ環境において、Fastify 5が依然として最高の選択である理由と、それを貫く核心的な構造および設計哲学を解説します。
高性能の秘密: radix-treeルーターとAvvioプラグイングラフ
Fastifyが既存のNode.jsフレームワークと比較して最大3倍高いスループットを実現する核心的な原動力は、専用ルーターと他に類を見ないプラグインアーキテクチャにあります。組み込みルーティングライブラリであるfind-my-wayは、ラディックスツリーアルゴリズムを活用し、登録されたパスがどれだけ増えても定数に収束する、極めて高速なパス検索性能を保証します。
もう一つの設計上の核心は、非同期プラグインの動作を制御するAvvioライブラリです。Fastifyは非巡回有向グラフの形式でプラグインの関係と読み込み順序を制御し、完璧なスコープカプセル化をサポートします。特定のスコープ内で宣言したデコレータやライフサイクル・フックが上位や兄弟スコープに漏れ出さず、内部のサブツリー内にのみ安全に分離されるため、副作用のないマイクロサービス設計が可能になります。
ここにJSONスキーマ仕様に基づきシリアライズコードを事前ビルドするfast-json-stringifyエンジンが加わります。標準 JSON.stringify 呼び出し方式の恒常的なランタイムオーバーヘッドを省略し、パフォーマンスのボトルネックを完全に回避することで、ハードウェアリソースを極限まで引き出します。
Type Provider: ビルド段階なしのリアルタイムなスキーマ型推論
Fastifyは、別途のビルド段階やスキーマコード生成なしにJSONスキーマをTypeScript型として直接マッピングするType Providerパターンをサポートします。ZodやTypeBoxのようなスキーマライブラリを使用してランタイムのバリデーションルールを宣言すれば、コンパイラがこれを理解し、開発時点で完全な静的型としてリアルタイムに推論してくれます。これにより、コードと検証スキーマが一致せずに発生する慢性的な同期エラーを根本的に予防できます。
最も広く使われている fastify-type-provider-zod を活用すれば、初期設定後、次のようにルートハンドラーで安全な型推論をすぐに享受できます。
import Fastify from 'fastify';
import { serializerCompiler, validatorCompiler } from 'fastify-type-provider-zod';
import type { ZodTypeProvider } from 'fastify-type-provider-zod';
import { z } from 'zod';
const server = Fastify().withTypeProvider<ZodTypeProvider>();
server.setValidatorCompiler(validatorCompiler);
server.setSerializerCompiler(serializerCompiler);
server.post('/users', {
schema: {
body: z.object({
name: z.string().min(2),
email: z.string().email()
})
}
}, async (req) => {
const { name, email } = req.body; // 별도의 타입 단언 없이 자동 추론
return { id: '1', name, email };
});このように定義されたスキーマは、ランタイムでの入力値検証だけでなくOpenAPIドキュメント規格とも連動し、開発生産性を最大化します。追加のビルドコンパイルレイヤーを回避しつつ、強力なバリデーションとドキュメント化のメリットをリアルタイムに結合してくれる、高性能設計の核心軸です。
Fastify 5移行時の摩擦と主な変更点
Fastify 5へメジャーバージョンを上げる際に最も先に体感される破壊的変更は、スキーマ定義規格の厳格化です。以前のバージョンまで利便性のために提供されていた jsonShorthand オプションが完全に削除されました。今後はクエリ文字列、リクエストボディ、レスポンスなどの検証スキーマを作成する際、最上位に明示的なオブジェクト型とプロパティを宣言する正式なJSONスキーマ規格を必ず遵守しなければなりません。
Fastify公式の移行ガイドに基づくスキーマ作成方法の変化は次の通りです。
// Fastify 4 (이전): 암묵적인 객체 래핑 허용
fastify.post('/user', {
schema: {
body: {
name: { type: 'string' }
}
}
}, handler);
// Fastify 5 (이후): 명시적인 JSON 스키마 구조 필수
fastify.post('/user', {
schema: {
body: {
type: 'object',
properties: {
name: { type: 'string' }
},
required: ['name']
}
}
}, handler);ネットワークおよび環境情報を扱うAPIにも、標準を遵守するための変更がありました。これまでは req.hostname 参照時にポート番号も含まれて返されていましたが、Fastify 5からはNode.js標準のURLオブジェクト規格に合わせて、ポートを除いたドメイン名のみが返されます。既存のホストとポートの組み合わせ情報が必要な場合は req.host や req.port を明示的に組み合わせて使用する必要があります。
また、デフォルトの検証エンジンであるAjvの時間フォーマット検証ルールも、さらに厳格になりました。これまでの'time'および'date-time'フォーマットは、必ず標準時間帯情報を含まないと検証を通過できないため、時間帯情報が流動的な環境であれば'iso-time'または'iso-date-time'フォーマットへ設定を切り替える移行作業が求められます。
Node.js vs Edgeランタイム: Fastifyの明確な限界とターゲット市場
Honoのような現代的なフレームワークが軽量なエッジやサーバーレス環境を掌握する一方で、FastifyはNode.jsランタイムにのみすべての能力を集中させました。これは単なる好みの違いではなく、Fastifyが超高速性能を出すために採用した核心アーキテクチャが、エッジ環境の制約条件と根本的に衝突するためです。
最大の障害は、パフォーマンス最適化の核心であるJITスキーマコンパイラの設計です。FastifyはAjvとfast-json-stringifyを活用し、ランタイムにeval関数でスキーマを動的コンパイルすることで、シリアライズ速度を通常のJSONと比較して数倍以上に引き上げます。しかし、Cloudflare WorkersやVercel EdgeのようなV8アイソレート分離環境では、セキュリティのために動的コード評価が完全に禁止されており、実行時に EvalError を吐き出して動作自体が不可能です。
また、FastifyのデフォルトロガーであるPinoが活用するマルチスレッドワーカーアーキテクチャや、 node:http 標準モジュールに対する深い依存性も、コンテキストが極めて制限されたサーバーレス環境では誤作動を引き起こす要因となります。APIScoutの分析によると、このような技術的特性のため、Fastifyは全世界のネットワークに分散配置されるエッジコンピューティングよりも、コンテナベースのマイクロサービスや独立した仮想サーバーで永続的に大規模なトラフィックを処理する伝統的なバックエンドアーキテクチャに最も適しています。
結局Fastifyは、あらゆるインフラプラットフォームを中途半端にサポートして個性を失う代わりに、Node.jsバックエンドインフラが提供するリソースを極限まで活用する王道を選択し、他にない高性能セグメントを構築することに成功しました。
インフラ目的に適した現実的なフレームワーク選択
Fastify 5は、エッジコンピューティングのトレンドに流されず、Node.js環境での高性能サーバー構築という核心価値に集中したフレームワークです。全世界のネットワークのエッジノードや軽量なサーバーレス環境を目指すならHonoのような軽量フレームワークが最適な選択になるかもしれませんが、コンテナクラスターや仮想サーバー環境で永続的なバックエンドサービスを安定的に運営する必要がある場合は、判断基準が変わります。このように大規模なトラフィック処理が重要な永続的サーバー環境では、強力な型安全性と圧倒的なスループットの両方を保証するFastify 5とType Providerの組み合わせが、開発生産性とインフラ効率の側面で最も魅力的な答えとなるでしょう。
参考リンク