Skip to content
Published on

モダンバックエンドフレームワーク 2025 — NestJS·Fastify·Hono·Elysia·Spring Boot·FastAPI·Go·Axum·tRPC·GraphQL·gRPC 完全比較 (シーズン7 第2回)

Authors

プロローグ — フレームワークの問いが戻ってきた

「どのバックエンドフレームワーク?」は2015年の問いに感じるが、戻ってきた。理由は実在する。

  • エッジとサーバーレスはコールドスタートに優しい設計を要求する: Hono、Elysia、Fastifyが再び重要。
  • TypeScriptの浸透がバックエンドをJava/Pythonから引き離した。
  • タイプセーフRPC (tRPC, gRPC, typed GraphQL) が「API契約」を第一級の関心事にした。
  • AI APIがSSE/WebSocketストリーミングを日常化した。

古顔 (Express, Django, Flask) は今も動く。だが2026年に新規開始するなら、より良いデフォルトがある。


1章. TypeScriptバックエンド

NestJS

  • Angular風DI、モジュール、デコレータ。
  • Springからの移行者向け。
  • モノリスからマイクロサービスへの話が強い。エンタープライズ、CRUD中心ドメイン向き。
  • 短所: ボイラープレート、Fastify/Honoより遅いコールドスタート。

Fastify

  • Node最速系。スキーマ先行 (JSON Schema) がキラー機能 — バリデーション·シリアライズ·OpenAPIを無料で。
  • 用途: スキーマバリデーション必須のREST、OpenAPI、ミドルウェア生態系。

Hono

  • エッジファースト。Cloudflare Workers、Bun、Deno、Node — 一つのコードベース。
  • ハンドラベース、小さなAPI、ゼロ依存。
  • 用途: エッジランタイム、SSR APIルート、小サービス。

Elysia

  • Bunネイティブ。型レベルルーティング — ルートがTS型になる。
  • Eden Treaty: 別スキーマなしのtRPC風エンドツーエンド型。
  • Bun上のベンチマークで最速TSフレームワーク。
  • 用途: Bun中心、中小サービス、密結合なFE/BE型。

概要

FrameworkRuntimeコールドスタート型エルゴノミクス生態系
NestJSNodeDI + デコレータ巨大
FastifyNodeJSON Schema
HonoEdge/Node/Bun/Deno非常に速成長中
ElysiaBun非常に速最高

2章. JVM — Spring Boot, Micronaut, Quarkus

Spring Boot

  • エンタープライズJavaのデフォルト。Spring Data、Security、Batch、Cloudの生態系は最強。
  • 2024–2025: 仮想スレッド(Project Loom)spring.threads.virtual.enabled で有効化。リアクティブコードの多くが不要に。
  • GraalVMネイティブイメージでコールドスタート ~50ms。
  • 短所: JVMメモリ、TS/Pythonより遅い開発ループ。

Micronaut / Quarkus

  • 起動最適化された代替。コンパイル時DIとリフレクションレス設計。
  • Quarkus + GraalVMネイティブは ~20MB / ~10ms 起動 — Lambda向き。

用途

  • エンタープライズ、規制産業、成熟チーム、長寿命サービス。
  • Spring Boot + 仮想スレッドは2026年の非常に良いデフォルト。

3章. Python — FastAPI, Litestar, Django Ninja

FastAPI

  • ASGI + Pydantic v2。自動OpenAPI。2023年にはPython Web標準。
  • 2024 v2: バリデーションがv1比5–10倍高速。
  • 用途: AI/ML隣接サービス、ラピッドプロトタイプ、Pythonデータスタック統合。

Litestar

  • FastAPI類似でより明確な構造。DIが第一級。
  • ベンチはわずかに速い。コミュニティ成長中。

Django Ninja

  • DjangoにFastAPIパターン。
  • 用途: Django ORM/admin既存、クリーンなRESTレイヤが欲しい。

注意

  • Python 3.13のフリースレッド (No-GIL) は2025年時点で実験的。本番にはまだ。

4章. Go — Fiber, Echo, Chi, Gin, net/http

net/httpのシフト (Go 1.22+)

  • 標準 net/httpメソッド + パスパラメータのルーティングが内蔵。サードパーティルーター不要なチーム増加。

サードパーティ

  • Chi — ミニマル、イディオマティック、ミドルウェアフレンドリー。
  • Echo — フル機能、強いミドルウェア。
  • Fiber — Express風API、fasthttp基盤 (net/http非互換)。
  • Gin — 速さとコミュニティで今も人気。

用途

  • 高スループット、低レイテンシ、シンプルなデプロイ。
  • Kubernetesネイティブサービス。

5章. Rust — Axum, Actix-web, Rocket

Axum

  • Tokio + Towerネイティブ。ハンドラスタイルはGoに近い感触。
  • マクロ軽め、タイプセーフなエクストラクタ、serdeファーストクラス。
  • 2025年のRust Web標準。

Actix-web

  • アクターモデル出身、生ベンチは今も最速。
  • エラー処理が複雑、初心者には優しくない。

用途

  • 一級の性能要件、エッジコンピュート、WASMバックエンド。
  • 性能クリティカルパスでGoを置換。

6章. APIスタイル — REST, tRPC, GraphQL, gRPC

REST + OpenAPI

  • 今も最も安全なデフォルト。キャッシュ可能、観測可能、公開API向き。
  • 2025年ツール: Scalar (ドキュメント)、RedoclyOrval (OpenAPIからのコード生成)、Hey API

tRPC

  • TS専用。コード生成なしでエンドツーエンド型。
  • 用途: 単一スタックTSモノレポ、Next.js + Node API。
  • 非用途: 公開API、多言語コンシューマ。

GraphQL

  • 強力なクライアント駆動クエリ、関係中心ドメイン。
  • 2024–2025: Federation v2成熟、Apollo Router in Rust、Hasura/PostGraphileでDB先行。
  • 短所: キャッシュ複雑、DataloaderなしでN+1リスク、CRUDには過剰。

gRPC / Connect

  • Protobufスキーマ、言語横断の型付きクライアント。Connect-RPCは一定義からHTTP + gRPC + gRPC-Web。
  • 用途: 内部サービス間、多言語マイクロサービス、ストリーミング。

クイック選択

  • 内部多言語マイクロサービス → gRPC/Connect。
  • 公開API → REST + OpenAPI。
  • 密結合FE/BEのTSモノレポ → tRPC。
  • 関係豊富なデータ、多クライアント形状 → GraphQL + Federation。

7章. バリデーションとスキーマ — Zod, Valibot, ArkType

  • Zod — TS圏のデフォルト、生態系巨大。
  • Valibot — tree-shakable (エッジ向けの小バンドル)、Zod互換メンタル。
  • ArkType — ランタイムバリデーション用のTS型構文。
  • TypeBox — JSON Schema先行、Fastifyのデフォルト。

スタック全体で一つに統一。混ぜると痛い。


8章. ORM / データ層

  • Prisma — スキーマ先行、良DX、v5で一部パスのRustエンジンを削減、TypedSQLで生クエリ。
  • Drizzle — SQL先行、エッジフレンドリー (エンジンバイナリなし)、急成長。
  • Kysely — クエリビルダ、マイグレーションなし。
  • TypeORM / MikroORM — 伝統的ORM、話題は減少。
  • Sequelize — レガシー、新規では避ける。
  • Spring Data JPA / Hibernate — JVMのデフォルト。
  • SQLAlchemy 2.0 — Pythonのデフォルト、非同期も安定。
  • sqlc (Go) — SQLから型付きコード生成。Goデータ層の実用解。
  • sqlx / SeaORM / Diesel (Rust) — コンパイル時チェック vs 使い勝手で選ぶ。

9章. 認証 — 2025年の景色

  • BetterAuth / Lucia v3 — TSファースト。Lucia v3は「非推奨、BetterAuthへ」。
  • Clerk / Auth0 / Stytch — マネージド認証。
  • Keycloak — セルフホスト、JVM。
  • Supabase Auth — Supabase Postgresと統合。
  • NextAuth v5 (Auth.js) — Next統合。
  • Passkey (WebAuthn) が2024年主流に。B2BではSCIM + SSOが期待される。

10章. 観測性

  • OpenTelemetry — ユニバーサル契約。モダンフレームワークはすべて対応。
  • Grafana + Prometheus + Tempo + Loki — OSSスタック。
  • Datadog / New Relic / Honeycomb — SaaS。
  • Sentry / PostHog — エラー + プロダクト分析。

ルール: トレースはフレームワーク層、ログはサービス層、メトリクスはシステム層。


11章. バックグラウンドジョブ

  • BullMQ (Redis) — Nodeのデフォルト。
  • Sidekiq — Ruby標準。
  • Celery — Python標準、Redis/RabbitMQ/SQS対応。
  • Temporal — 耐久実行。cron + リトライ + 状態機械を置換。
  • Inngest / Trigger.dev — TS向けサーバーレスジョブランナー。
  • pgmq — PostgresメッセージキューでRedis回避。

Temporalは複雑な多段ワークフローでの2025年の第一選択。


12章. デプロイ — 「そのまま動く」ランタイム + フレームワーク組み合わせ

  • Vercel + Next.js (または Hono) — ゼロ設定、エッジフレンドリー。
  • Cloudflare Workers + Hono — 最小グローバルレイテンシ。
  • Railway / Render / Fly.io — コンテナ風デプロイで伝統的フレームワーク。
  • AWS Lambda + FastAPI (Mangum) / Spring Boot (GraalVM) — エンタープライズサーバーレス。
  • Kubernetes + 任意 — 大規模チーム、規制環境。
  • Bun + Elysia + Bun Deploy (2025) — 新興、注目。

13章. 意思決定ツリー

Q1: エッジ/サーバーレスターゲット?
├─ はい: Hono (エッジ), Elysia (Bun), FastAPI (Lambda), Quarkus (ネイティブ)
└─ いいえ → Q2

Q2: TSモノレポ、FE/BE密結合?
├─ はい: Next.js API / tRPC / Hono
└─ いいえ → Q3

Q3: エンタープライズJava/Kotlin、規制?
├─ はい: Spring Boot (+ 仮想スレッド)
└─ いいえ → Q4

Q4: 高スループット / 低レイテンシ必須?
├─ はい: Go (Fiber/Echo/Chi) or Rust (Axum)
└─ いいえ → Q5

Q5: Pythonデータ/AI隣接?
├─ はい: FastAPI / Litestar
└─ いいえ: NestJS or Fastify

12項目導入チェックリスト

  1. チームの言語/ランタイム強みはマッピング済み?
  2. コールドスタート予算を定義?
  3. フロントエンドとの型共有計画は?
  4. OpenAPIまたはスキーマの真実源は決定?
  5. ORMは規模とマイグレーション考慮で選定?
  6. バックグラウンドジョブランナー選定?
  7. 認証ライブラリ決定 (セルフホスト vs マネージド)?
  8. 観測性スタックを初日から統合?
  9. レート制限/不正防止を層化?
  10. ローカル開発がProdに一致 (Docker/Bun/Nodeパリティ)?
  11. テスト戦略 — ユニット + 統合 + 契約?
  12. デプロイパイプライン自動化、ロールバックテスト済?

よくあるアンチパターン10

  1. 500行サービスに「念のため」NestJS。
  2. 3つのRESTで済むところにGraphQL。
  3. サーバーレスでコールドスタート無視 — 巨大フレームワーク + 重いDI。
  4. 共有スキーマをフロントエンド型から盗む (ドリフト地獄)。
  5. エッジでのスキーマバリデーションなし (全エラーが後で500になる)。
  6. ループ内のORMレイジーロード — N+1が1000+1に。
  7. Lambdaでの長寿命DBコネクション — コネクション爆発。
  8. 認証を一から自作 — ミスが必ず起きる。
  9. OpenAPIなし → クライアントコード生成なし → 手書きfetch。
  10. 「Kubernetesがあるから」でKubernetesデプロイ — 過剰装備が多い。

次回予告

シーズン7 第3回 — 分散データベース 2025: CockroachDB、Spanner、TiDB、Yugabyte、Aurora DSQL、Neon、PlanetScale、Turso、D1。「ベスト」ではなく「選び方」。

— モダンバックエンドフレームワーク編、完。