Fastify 5を業務アプリの骨格にするmarcoturi/fastify-boilerplate
Fastify 5 アプリケーション ボイラープレートは、クリーン アーキテクチャ、ドメイン駆動設計、CQRS、関数型プログラミング、実稼働グレードのアプリケーションを構築するための垂直スライス アーキテクチャに基づいています。
ひと目でわかる
- これは何？
- Node.js 24のネイティブTypeScript実行、DDDとCQRS、RESTとGraphQL、PostgreSQLを組み合わせた構成をREADMEから検証する。
- 誰に向いている？
- 業務ルールをHTTPフレームワークから切り離し、RESTとGraphQLの両方を持つTypeScriptサービスを始めたいチームに向きます。単純な小規模APIには構成が重くなり得るため、まず pnpm check、pnpm test、pnpm deps:validate を実行し、PostgreSQL接続と生成された client/ の差分を確認してから採用範囲を決めてください。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 2 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Node.js 24を前提にしたスターターの輪郭
marcoturi/fastify-boilerplateは、Fastify 5で本番向けアプリケーションを始めるためのTypeScript製ボイラープレートです。READMEが掲げる中心は、Clean Architecture、ドメイン駆動設計、CQRS、関数型プログラミング、垂直スライスです。Node.js 24以上の型ストリッピングを使うため、通常のトランスパイル工程を置かない点がこのテンプレートの前提になります。pnpm 10以上とPostgreSQLも必要です。
採用時に見るべき点は、機能の多さより境界の置き方です。Fastify、Awilix、Pino、TypeBox、Mercurius、Postgres.js、DBMateが一つの開発体験に収められていますが、READMEは個々の採用技術の性能保証をしていません。スター数や「production-ready」という表現も、利用環境での検証結果とは分けて扱う必要があります。
RouteからRepositoryへ流れる依存方向
コードの依存は Route → Handler → Domain → Repository の一方向です。コア部分はFastifyに直接依存せず、ハンドラはREST、GraphQL、gRPC、CLIなどのプロトコルから切り離せる設計です。SQLはリポジトリに限定され、ドメインサービスには純粋な業務ロジックを置きます。src/modules配下では、ドメイン概念ごとの垂直スライスに必要な部品をまとめます。
モジュール間の直接インポートを避け、コマンドとクエリはCQRSバス、通知だけで済む処理はイベントで連絡します。CQRSハンドラの境界を後のサービス分割に利用できるという説明はありますが、実際に分割済みの構成やネットワーク運用はREADMEにありません。小さなCRUDでは全レイヤーを強制せず、ハンドラからリポジトリへ進める例外も明記されています。
RESTとGraphQLを同じスキーマから扱う
APIにはTypeBoxスキーマを使うREST、Mercuriusを使うGraphQL、開発時のGraphiQLが用意されています。起動後に確認できる入口は /health、/api-docs、/api-docs/json、/graphql です。RESTのOpenAPI 3.1.0 JSONとGraphQLの型をクライアントパッケージとして生成し、リリース時にnpmへ公開する流れも含まれます。
この構成は、サーバー側の契約を型へ戻したいチームには便利です。一方、pnpm generate:types はサーバーとDBを起動してスキーマを取得し、client/へ書き込む処理です。生成物をレビュー対象にするのか、CIで毎回比較するのかは利用側で決める必要があります。
pnpm create:envからlocalhost:3000まで
開始手順は、npx degit marcoturi/fastify-boilerplate my-app で雛形を取り、pnpm install、pnpm create:env、docker compose up postgres -d、pnpm db:migrate、pnpm start の順です。標準の開発サーバーは http://localhost:3000 で待ち受けます。Dockerを使わずローカルPostgreSQLを選ぶ場合は、.envの接続値を調整します。
本番用にはAlpineを使うマルチステージDockerfileがあり、非rootのfastifyユーザー、dumb-init、30秒間隔で /health を見るHEALTHCHECKが含まれます。イメージの構成が自分の監視・権限方針に適合するかは、Dockerfileとdocker-compose.ymlを読んで確認すべきです。
node:test、Cucumber、k6を分けた検証層
pnpm test はnode:testによるユニット・統合テストの入口です。ソースの隣に *.spec.ts を置き、E2EはGherkinとCucumber.jsで実行します。E2Eには稼働中のPostgreSQLが必要ですが、buildApp()を使ってポートを開かずにFastifyインスタンスを組み立てる方式も説明されています。負荷試験にはk6を使います。
品質確認の入口は pnpm check で、Biomeによるlintとフォーマット、型チェックをまとめて走らせます。pnpm deps:validate はdependency-cruiserでレイヤー境界を検査します。これらは設計意図を継続的に確認する仕組みですが、アプリケーション固有の性能目標や障害復旧手順を代替するものではありません。
OpenTelemetryを無効状態から接続する
src/instrumentation.tsにはベンダー非依存のOpenTelemetry設定があります。OTLPを通してバックエンドを選べ、HTTPとFastifyのリクエスト、CQRSのコマンド・クエリ・イベントをトレース対象にします。既定では OTEL_SDK_DISABLED=true で無効化され、READMEは無効時のオーバーヘッドをゼロと説明しています。
有効化する場合は、選んだコレクターの接続先、サンプリング、機密データの扱いを環境に合わせて確認します。AGENTS.mdにはAIアシスタント向けのアーキテクチャ規則とコーディング規約が記載されています。AIで変更を作る場合も、pnpm checkとpnpm deps:validateを通す運用がこのリポジトリの境界を守る基準になります。
導入判定では、src/modulesの一機能を選び、RouteからRepositoryまでの依存をdependency-cruiserで確認します。PostgreSQLをdocker composeで起動した状態と停止した状態を分け、pnpm db:migrateの結果、GET /health、/api-docs/jsonのスキーマ、GraphQLの応答を保存します。OpenTelemetryを有効にした時はCQRSのトレースが出ること、無効時は環境変数が反映されることを確認します。これで、雛形の構造が自社の開発規約へ持ち込めるかを具体的に判定できます。
Fastify 5の版、Node.js 24、pnpm 10、PostgreSQLの接続値を固定し、雛形から作った一つのAPIで導入手順を再現します。生成型の差分とOpenTelemetryの有無を同じコミットで比較します。
Node.jsの型ストリッピングとpnpmの版を揃え、docker composeのPostgreSQLを使ったマイグレーションを確認します。RESTとGraphQLのスキーマを生成し、CIの依存境界検査まで通った状態を基準にします。
OpenAPI生成物、GraphQL型、DBマイグレーション、healthcheckを同じリリース候補で照合し、client/の変更が意図した契約だけであることを確認します。
編集部の結論
業務ルールをHTTPフレームワークから切り離し、RESTとGraphQLの両方を持つTypeScriptサービスを始めたいチームに向きます。単純な小規模APIには構成が重くなり得るため、まず pnpm check、pnpm test、pnpm deps:validate を実行し、PostgreSQL接続と生成された client/ の差分を確認してから採用範囲を決めてください。
コミュニティノート