Split View: Modern Backend Framework 2025 — NestJS·Fastify·Hono·Elysia·Spring Boot·FastAPI·Go·Rust·tRPC·GraphQL·gRPC 완전 비교 (Season 7 Ep 2)

Modern Backend Framework 2025 — NestJS·Fastify·Hono·Elysia·Spring Boot·FastAPI·Go·Rust·tRPC·GraphQL·gRPC 완전 비교 (Season 7 Ep 2)

프롤로그 — "어떤 프레임워크를 써야 하나요?"

10년 차 백엔드 엔지니어가 신입에게 자주 듣는 질문. 답은 "때에 따라"다. 그런데 이 "때"가 무엇인지 감이 오지 않으니 답답하다.

2025년 백엔드 프레임워크의 지형은 언어별로 몇 개의 대표 선수가 자리 잡은 안정기에 접어들었다. 10년 전 "Spring이냐 Node냐"는 식의 거대한 경합은 끝났고, 이제는 **"우리 팀의 맥락에서 무엇이 맞는가"**를 고르는 게임이다.

이번 글에서는 13개 챕터로 2025년 백엔드 프레임워크의 지도를 그리고, API 패러다임(REST·tRPC·GraphQL·gRPC), 그리고 선택 기준을 정리한다.

1장 · 프레임워크 선택의 7가지 축

프레임워크를 고를 때 고려할 축:

언어 — 팀이 숙련된 언어, 채용 가능성
타입 시스템 — 정적·동적, 타입 추론 강도
성능 — RPS·latency·메모리
생태계 — ORM·인증·모니터링 라이브러리
표현력 — 같은 기능을 몇 줄로
학습 곡선 — 온보딩 시간
커뮤니티·장기 지원 — 5년 후에도 살아있을 가능성

**"빠르니까 Rust"**는 젊은 엔지니어의 로맨스다. Rust가 빠르다고 해서 팀 전체가 Rust로 전환할 때 얻는 이득이, 학습·생산성 감소·인력 확보 비용을 상쇄할지 계산이 필요하다.

이 글의 모든 프레임워크는 "베스트"가 아니라 "쓸 만한 선수들"이다.

2장 · Node/Bun/Deno 진영 — NestJS·Fastify·Hono·Elysia

NestJS — "엔터프라이즈 TypeScript의 Spring"

Angular에서 영감. Controller·Service·Module·DI·Pipe·Guard
TypeScript first. 데코레이터 기반
Microservice 지원 (gRPC·NATS·Kafka·Redis Pub/Sub·RabbitMQ 내장 transporter)
대기업·엔터프라이즈 선호
학습 곡선 있음. 프로젝트 작으면 과함

@Controller("users")
export class UsersController {
  constructor(private readonly users: UsersService) {}

  @Get(":id")
  findOne(@Param("id") id: string) {
    return this.users.findOne(id);
  }
}

Fastify — "빠른 Express의 후계자"

Express의 정신적 후계자. Schema 기반 직렬화로 10배 빠름
JSON Schema를 선언하면 validator + fast serializer + OpenAPI 자동
Plugin 아키텍처로 모듈화
Node.js에서 가장 성숙한 경량 프레임워크

Hono — 런타임 중립의 새 스타

Node·Bun·Deno·Workers·Vercel Edge·Fastly 모두 동일 코드
초경량(~20KB), 빠름, TypeScript first
OpenAPI 통합, zod validation

import { Hono } from "hono";
import { zValidator } from "@hono/zod-validator";
import { z } from "zod";

const app = new Hono();
app.post(
  "/users",
  zValidator("json", z.object({ email: z.string().email() })),
  (c) => c.json({ ok: true })
);
export default app;

Elysia — Bun 전용 속도 괴물

Bun 최적화. Fastify보다 2~3배 빠름 (합성 벤치 기준)
Static code analysis로 엄청난 타입 추론
WebSocket·Stream 내장
Bun 종속이 유일한 약점

선택

대형·엔터프라이즈: NestJS
성능·경량 API: Fastify 또는 Hono
Edge·풀스택: Hono
Bun 극한 속도: Elysia

3장 · JVM 진영 — Spring Boot·Quarkus·Micronaut·Ktor

Spring Boot — 엔터프라이즈의 왕

2014년부터 JVM 표준
생태계 압도적 (Security·Data·Cloud·Batch·Integration)
2024년 Spring Boot 3.x + Java 21 Virtual Threads로 스케일링 혁신
단점: 시작 속도·메모리 (cold start 수 초)

@RestController
@RequestMapping("/users")
public class UserController {
    private final UserService service;

    public UserController(UserService service) {
        this.service = service;
    }

    @GetMapping("/{id}")
    public User findOne(@PathVariable String id) {
        return service.findOne(id);
    }
}

Quarkus — Serverless 시대의 JVM

Red Hat 주도. "Supersonic Subatomic Java"
GraalVM Native Image 컴파일로 시작 시간 100ms 이하
Kubernetes·Serverless에 최적
2025년 Spring의 강한 대안으로 부상

Micronaut

Compile-time DI (reflection 없음)
빠른 시작, 작은 메모리
Kotlin·Groovy·Java 지원

Ktor — Kotlin 네이티브

JetBrains 공식
Coroutine 기반 비동기
DSL 스타일, 간결함
네이버·토스·카카오의 Kotlin 서비스에서 사용

선택

전통 엔터프라이즈: Spring Boot
Serverless·Kubernetes: Quarkus
Kotlin 중심: Ktor
시작 속도: Micronaut 또는 Quarkus

4장 · Python 진영 — FastAPI·Django·Litestar·Flask

FastAPI — 현대 Python의 de facto

2018년 Sebastián Ramírez 작
Pydantic + async → 자동 validation + OpenAPI
Starlette 기반, uvicorn/hypercorn 런타임
2024~2025년 주간 다운로드 압도적 1위

from fastapi import FastAPI
from pydantic import BaseModel, EmailStr

app = FastAPI()

class UserIn(BaseModel):
    email: EmailStr
    age: int

@app.post("/users")
async def create(u: UserIn):
    return {"ok": True, "email": u.email}

Django — 풀스택 배터리 포함

20년 역사, 여전히 관리자 패널·ORM·Auth·Admin이 매력
Django Ninja로 FastAPI 스타일 개발 가능
주요 장점: 관리자·Admin·보안 기본값이 훌륭

Litestar (구 Starlite)

FastAPI의 대안, 더 빠르고 더 유연하다고 주장
DI·Controllers·Routers·OpenAPI
작지만 신성장 커뮤니티

Flask

여전히 널리 쓰이지만 신규 프로젝트에서 FastAPI로 대체 경향
마이크로서비스·스크립트에 적합

선택

API 중심 신규: FastAPI 또는 Litestar
풀스택·관리자 앱: Django
단순·레거시 마이그레이션: Flask
과학 계산·AI 서비스: FastAPI + Ray/Celery

5장 · Go 진영 — Gin·Echo·Chi·Fiber·Huma

왜 Go인가

컴파일 속도·단일 바이너리·goroutine·GC
Kubernetes·Docker·Prometheus·Terraform의 언어
한국 대기업 백엔드·인프라 팀에서 증가

Gin — 가장 인기

Martini 스타일 미들웨어·라우터
주간 다운로드 Go 웹 1위
단순·빠름

r := gin.Default()
r.GET("/users/:id", func(c *gin.Context) {
    id := c.Param("id")
    c.JSON(200, gin.H{"id": id})
})
r.Run(":8080")

Echo

Gin과 유사, 더 풍부한 middleware
WebSocket·Auto TLS 내장

Chi

Go idiomatic 철학, net/http 호환
가장 얇은 라우터
대형 서비스에서 선호

Fiber

Express 스타일 API
fasthttp 기반 (표준 net/http 안 씀 → 호환성 주의)
극단적으로 빠름

Huma

OpenAPI first — 타입만 정의하면 문서·validator 자동
2024~2025년 부상

선택

빠른 시작: Gin, Fiber
표준 중심·대형: Chi
OpenAPI·타입 안전: Huma

6장 · Rust 진영 — Axum·Actix·Rocket·Poem

왜 Rust인가

컴파일 타임 메모리 안전
GC 없음, 예측 가능한 latency
극도로 빠름 (Go보다 2~3배 cases)
학습 곡선 높음

Axum — 가장 뜨거운

Tokio 팀이 만듦
Type-safe routing, tower middleware
Tokio·Hyper 기반
2024년부터 Rust 웹의 사실상 1위

use axum::{routing::get, Router};

#[tokio::main]
async fn main() {
    let app = Router::new().route("/", get(|| async { "Hello" }));
    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

Actix Web

오래된 1강. 성능 벤치마크 최상위
Actor 모델 기반
API 복잡도 높음

Rocket

DSL 우아함
과거 nightly 필요 → 2023년 stable 지원
학습에 친화적

Poem

OpenAPI·GraphQL·gRPC 내장
Rust에서 "all-in-one" 선택

선택

처음 Rust 웹: Axum 또는 Rocket
극한 성능: Actix
일체형 도구: Poem

7장 · tRPC — TypeScript End-to-end 타입

2020년 Alex Johansson 작. "TypeScript Type을 API 계약으로".

동작 원리

서버에서 함수를 procedure로 등록
클라이언트는 타입이 자동 추론됨
스키마·OpenAPI 작성 없이 풀스택 타입 공유

// server.ts
export const appRouter = router({
  user: router({
    byId: publicProcedure
      .input(z.object({ id: z.string() }))
      .query(({ input }) => db.user.findUnique({ where: input })),
  }),
});
export type AppRouter = typeof appRouter;

// client.ts
const user = await trpc.user.byId.query({ id: "abc" });
// user: User | null — 완전 타입 추론

장점

설정·보일러플레이트 최소
컴파일 시 계약 불일치 감지
Next.js·Remix·Expo 풀스택에 최적

한계

TypeScript 클라이언트 전용 — 다른 언어 클라이언트는 OpenAPI 별도
마이크로서비스 간 통신에는 부적합 (서비스마다 TypeScript가 아닐 수 있음)

2025 권장

단일 저장소 Next/Remix 풀스택 → tRPC 강력 추천
다언어·공개 API → OpenAPI 기반 REST 또는 gRPC

8장 · REST vs GraphQL vs gRPC

REST

HTTP 메서드 + 리소스
캐싱·프록시·CDN과 궁합 최고
OpenAPI 3.1로 스키마·클라이언트·문서 자동 생성
여전히 2025년 대다수 공개 API의 표준

GraphQL

2015년 Facebook 공개
필드 단위 요청 — 오버페칭 해소
한 엔드포인트·복잡한 스키마
단점: 캐싱 어려움, N+1, 학습 곡선
2024~2025년 많은 대기업이 "GraphQL Federation → REST로 회귀" 사례. 단순 CRUD엔 과함.

gRPC

Google, Protobuf 기반 바이너리
마이크로서비스 간 통신 최적
서버 스트리밍·양방향 스트림 지원
HTTP/2 필수 → 브라우저 직접 호출 어려움 (gRPC-Web 필요)
2025년 내부 서비스 통신의 de facto

Connect-RPC

gRPC의 단점(브라우저 호환) 해결
HTTP/1.1·HTTP/2 동시 지원
TypeScript·Go·Swift·Kotlin 클라이언트
"gRPC + REST의 좋은 면"

선택

공개 API: REST + OpenAPI
마이크로서비스 내부: gRPC 또는 Connect
복잡한 다중 엔티티 뷰: GraphQL (선별적)
타입 안전 풀스택: tRPC

9장 · ORM·Query Builder 선택

프레임워크 위에 올리는 DB 레이어.

TypeScript/JS

Prisma — 타입 추론 강력, Migration·Studio UI
Drizzle ORM — Edge 호환, SQL에 가까움, 빠름
Kysely — Query Builder, 최대 타입 안전
TypeORM — 오래된 선택, 점유 하락

Python

SQLAlchemy 2.0 — 2.0에서 async 네이티브
Django ORM — Django 생태계
Tortoise ORM — FastAPI·async 중심

Java/Kotlin

JPA/Hibernate — Spring 기본
jOOQ — Query Builder, 타입 안전
Exposed — Kotlin DSL

Go

GORM — 가장 인기
Ent — Facebook, graph 모델
sqlc — SQL 파일 → Go 코드 생성

Rust

SQLx — compile-time checked SQL
SeaORM — Django 스타일 ORM
Diesel — 가장 오래된 Rust ORM

2025 조언

**"ORM vs Raw SQL"**은 스펙트럼이다
복잡한 분석 쿼리는 Raw SQL
단순 CRUD는 ORM/Query Builder
N+1 쿼리는 모든 ORM의 숙제

10장 · 인증·세션·RBAC

2025 인증 표준

OAuth 2.1 + OIDC 공개 API
Passkey·WebAuthn 1차 사용자 인증
JWT·PASETO 세션 토큰
Session Cookie도 여전히 유효

프레임워크별 패턴

NestJS: @nestjs/passport, @nestjs/jwt
Spring: Spring Security
FastAPI: fastapi-users, authlib
Rails: Devise
Go: 직접 구현 or golang-jwt/jwt
Rust: axum-login, tower-sessions

Auth as a Service

Auth0·Clerk·Stytch·WorkOS·Kinde·SuperTokens·Keycloak
2025년 대기업·스타트업 모두 SaaS 선호 증가

RBAC vs ABAC

RBAC: 역할 기반 (admin·editor·viewer)
ABAC: 속성 기반 (사용자·리소스·환경 조합)
조직 권한 복잡 → OpenFGA·Oso·Cerbos 권장

11장 · 모노리스 vs 마이크로서비스 vs BFF

2020년대 초의 반성

2010년대 "모든 것은 마이크로서비스"의 유행 이후, 많은 팀이 복잡도 폭발을 경험. 2024~2025년은 **"먼저 모노리스, 필요할 때 쪼개라"**가 중론.

Modular Monolith

단일 배포 가능 단위
내부는 모듈·패키지로 엄격 분리
성장하면 일부 모듈만 분리

Microservice

독립 배포·스케일
팀 경계·도메인 경계와 일치
Saga·분산 트랜잭션·관측성 비용 큼

BFF (Backend for Frontend)

프론트엔드마다 전용 백엔드
모바일·웹·IoT·AI 에이전트 각각의 BFF
GraphQL 또는 tRPC가 BFF 레이어에 적합
Apollo Federation·Envoy Gateway·BFF Edge

선택

1-10명 팀: Modular Monolith
10-50명: 도메인별 서비스 + BFF
50+: 다수 Microservice + Platform 팀

12장 · 프레임워크가 아닌 것 — "Boring Technology"

Dan McKinley의 Boring Technology

조직이 감당할 수 있는 혁신의 토큰은 유한
이미 검증된 기술에 대부분을 쓰고, 새 기술은 한 두 개만
"최신 기술 스택으로 쌓아 올린 서비스"는 일반적으로 더 빨리 무너진다

2025년의 Boring Stack 예시

Next.js + tRPC + Prisma + Postgres + Vercel (풀스택 TS)
Spring Boot + JPA + MySQL + Kubernetes (JVM 엔터프라이즈)
FastAPI + SQLAlchemy + Postgres + AWS ECS (Python)
Ruby on Rails + Postgres + Heroku/Render (빠른 시작)

"지루한" 기술의 장점

문서·커뮤니티·Stack Overflow가 풍부
채용 가능성 높음
5-10년 뒤에도 유지보수 가능
AI 도구와의 궁합 좋음 (학습 데이터 많음)

혁신 토큰을 어디에 쓸까

핵심 경쟁력에 쓰자 (AI 모델·알고리즘·데이터 파이프라인)
웹 프레임워크·DB 선택 같은 "기본"에는 검증된 것 사용

13장 · 체크리스트·안티패턴·다음 글 예고

프레임워크 선택 체크리스트 (14개)

팀 언어 역량이 첫 번째 기준
정적 타입 가용성 (TypeScript·Java·Kotlin·Rust)
채용 시장에서 구할 수 있는 엔지니어
배포 환경과 궁합 (Serverless·Kubernetes·VM·Edge)
성능 요구가 실제로 있는가 (대부분은 DB가 병목)
생태계 의존성 — ORM·Auth·Monitoring·Queue
API 표준 선택 (REST·tRPC·GraphQL·gRPC)
관측성 — OpenTelemetry 통합
DevOps — Docker·CI·배포 난이도
문서·학습 자료 한국어 여부
장기 지원 — 최소 3-5년 유지될 것인가
보안 업데이트 주기
팀 학습 곡선과 온보딩 비용
Boring Technology 원칙 — 혁신 토큰 아껴라

프레임워크 안티패턴 TOP 10

"최신이라서" 선택 — 벤치마크만 보고 결정
마이크로서비스 먼저 — 분산 복잡도를 처음부터
GraphQL을 단순 CRUD에 — 오버엔지니어링
Framework A + Framework B 섞기 — 경계 모호
ORM·Raw SQL 혼용 — 어느 쪽도 제대로 안 됨
인증 직접 구현 — Auth SaaS·표준 라이브러리
모니터링·로깅 나중에 — 시작부터 탑재
벤치마크 숫자 신뢰 — 실전 병목은 DB·네트워크
타입 없는 API 경계 — OpenAPI·tRPC·Protobuf
언어·프레임워크를 개인 취향으로 선택 — 팀 합의 없음

다음 글 예고 — Season 7 Ep 3: "데이터베이스 2025"

프레임워크 선택의 다음은 데이터 저장소. Ep 3은 2025년 데이터베이스.

Postgres의 지배 — 왜 모두 Postgres로 회귀하나
Distributed SQL: CockroachDB·Spanner·TiDB·YugabyteDB·Neon
NoSQL의 성숙: MongoDB·DynamoDB·Cassandra·Redis
Vector DB: pgvector·Pinecone·Weaviate·Qdrant·Milvus
Time Series: TimescaleDB·InfluxDB·QuestDB
Graph: Neo4j·ArangoDB·Neptune·PostgreSQL Graph
Edge DB: D1·Turso·Supabase·Neon Branch
SQLite의 재발견 — libSQL·Turso·Cloudflare D1
Serverless Postgres: Neon·PlanetScale·Supabase·Xata
샤딩·레플리케이션·Read Replica
한국 서비스의 DB 선택 사례

"프레임워크는 6개월마다 바뀌어도, DB는 10년을 간다."

다음 글에서 만나자.

"좋은 프레임워크는 팀의 속도와 품질을 동시에 높인다. 나쁜 프레임워크는 둘 다 떨어뜨린다. 그 차이는 기술 스펙이 아니라 팀과의 맞물림에서 온다."

— Season 7 Ep 2.

Modern Backend Frameworks 2025 — NestJS, Fastify, Hono, Elysia, Spring Boot, FastAPI, Go, Axum, tRPC, GraphQL, gRPC (S7 E2)

Prologue — the framework question is back

"Which backend framework?" feels like a 2015 question. But it's back — for real reasons:

Edge and serverless demand cold-start-friendly designs: Hono, Elysia, Fastify matter again.
TypeScript everywhere pulled backends away from Java/Python.
Type-safe RPC (tRPC, gRPC, typed GraphQL) made "API contract" a first-class concern.
AI APIs forced backends to stream SSE/WebSockets at scale.

Old favorites (Express, Django, Flask) still work. But if you're starting new in 2026, you have a better default.

1. TypeScript backends

NestJS

Angular-flavored DI, modules, decorators.
Fits teams coming from Spring.
Monolith-to-microservice story strong. Good for enterprises, CRUD-heavy domains.
Downsides: boilerplate, slower cold-start than Fastify/Hono.

Fastify

The raw-speed Node framework. Schema-first (JSON Schema) is the killer feature — validation, serialization, and OpenAPI for free.
Use when: REST APIs with schema validation, OpenAPI required, middleware ecosystem wanted.

Hono

Edge-first. Runs on Cloudflare Workers, Bun, Deno, Node — one codebase.
Handler-based, small API surface, zero deps.
Use when: deploying to edge runtimes, SSR API routes, small services.

Elysia

Bun-native. Type-level routing — routes become a TS type.
Eden Treaty: tRPC-like end-to-end types without a separate schema.
Fastest TS framework in raw benchmarks (on Bun).
Use when: Bun shop, small/medium services, tight FE/BE type coupling.

Quick table

Framework	Runtime	Cold-start	Type ergonomics	Ecosystem
NestJS	Node	Slow	DI + decorators	Huge
Fastify	Node	Fast	JSON Schema	Large
Hono	Edge/Node/Bun/Deno	Very fast	Good	Growing
Elysia	Bun	Very fast	Best-in-class	Small

2. JVM — Spring Boot, Micronaut, Quarkus

Spring Boot

Default for enterprise Java. Ecosystem unmatched: Spring Data, Security, Batch, Cloud.
2024–2025: virtual threads (Project Loom) via spring.threads.virtual.enabled — most reactive code becomes unnecessary.
GraalVM native images drop cold-start to ~50ms.
Downsides: JVM memory, slower dev loop than TS/Python.

Micronaut / Quarkus

Startup-optimized alternatives. Compile-time DI and reflection-less design.
Quarkus + GraalVM native is ~20MB / ~10ms startup — Lambda-friendly.

Use when

Enterprise, regulated industries, mature teams, long-lived services.
Spring Boot + Virtual Threads is a very good default in 2026.

3. Python — FastAPI, Litestar, Django Ninja

FastAPI

ASGI + Pydantic v2. Automatic OpenAPI. Defacto Python web standard by 2023.
2024 V2: 5–10× faster validation than v1.
Use when: AI/ML-adjacent services, rapid prototyping, Python data stack integration.

Litestar

FastAPI-alike with more opinionated structure. Dependency injection first-class.
Slightly faster benchmarks. Growing community.

Django Ninja

FastAPI patterns inside Django.
Use when: already on Django ORM/admin, need a clean REST layer.

Note

Python 3.13 free-threaded (no-GIL) is experimental in 2025; don't bet production on it yet.

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

The net/http shift (Go 1.22+)

Go's standard net/http got routing with methods and path params built-in. Many teams drop third-party routers.

Third-party

Chi — minimal, idiomatic, middleware-friendly.
Echo — full-featured, strong middleware.
Fiber — Express-like API, fasthttp-based (NOT net/http-compatible).
Gin — still popular for raw speed and community.

Use when

High throughput, low latency, simple deployment.
Kubernetes-native services.

5. Rust — Axum, Actix-web, Rocket

Axum

Tokio + Tower ecosystem native. Handler style feels Go-ish.
Macro-light, type-safe extractors, first-class serde.
Default Rust web framework in 2025.

Actix-web

Actor model origin, still the fastest in raw benchmarks.
More complex error handling, less newcomer-friendly.

Use when

Tier-1 performance needs, edge compute, WASM backends.
Replacing Go in performance-critical paths.

6. API styles — REST, tRPC, GraphQL, gRPC

REST + OpenAPI

Still the safest default. Cachable, observable, public APIs.
2025 tools: Scalar (docs), Redocly, Orval (codegen from OpenAPI), Hey API.

tRPC

TS-only. End-to-end types without code generation.
Use when: single-stack TS monorepo, Next.js + Node API.
Not for: public APIs, polyglot consumers.

GraphQL

Powerful client-driven queries, relationship-heavy domains.
2024–2025: Federation v2 mature, Apollo Router in Rust, Hasura/PostGraphile for database-first.
Downsides: caching complexity, N+1 risk without Dataloader, overkill for CRUD.

gRPC / Connect

Protobuf schemas, typed clients across languages. Connect-RPC gives HTTP + gRPC + gRPC-Web from one definition.
Use when: internal service-to-service, polyglot microservices, streaming.

Quick picks

Internal polyglot microservices → gRPC/Connect.
Public API → REST + OpenAPI.
TS monorepo with tight FE/BE coupling → tRPC.
Relationship-rich data, many client shapes → GraphQL with Federation.

7. Validation and schemas — Zod, Valibot, ArkType

Zod — default in TS land. Big, rich, ecosystem huge.
Valibot — tree-shakable (tiny bundle for edge), Zod-compatible mental model.
ArkType — TS type syntax for runtime validation.
TypeBox — JSON Schema-first, Fastify's default.

Pick one across the stack — mixing is painful.

8. ORM / data layer

Prisma — schema-first, great DX, v5 dropped Rust engine in some paths, TypedSQL for raw queries.
Drizzle — SQL-first, edge-friendly (no engine binary), gaining fast.
Kysely — query builder, no migrations.
TypeORM / MikroORM — traditional ORM approach, less hype.
Sequelize — legacy, avoid for new projects.
Spring Data JPA / Hibernate — default on JVM.
SQLAlchemy 2.0 — Python's default, async support solid.
sqlc (Go) — generates typed code from SQL. Pragma of Go data layer.
sqlx / SeaORM / Diesel (Rust) — pick based on compile-time checks vs ergonomics.

9. Auth — the 2025 landscape

BetterAuth / Lucia v3 — TS-first auth libraries. Lucia v3 is now "deprecated, migrate to BetterAuth."
Clerk / Auth0 / Stytch — managed auth.
Keycloak — self-hosted, JVM.
Supabase Auth — bundled with Supabase Postgres.
NextAuth v5 (Auth.js) — Next-integrated.
Passkeys (WebAuthn) went mainstream in 2024. SCIM + SSO expected for B2B.

10. Observability

OpenTelemetry — the universal contract. All modern frameworks support OTel.
Grafana + Prometheus + Tempo + Loki — OSS stack.
Datadog / New Relic / Honeycomb — SaaS.
Sentry / PostHog — for error + product analytics.

Rule: instrument traces at the framework layer, logs at the service layer, metrics at the system layer.

11. Background jobs

BullMQ (Redis) — default in Node.
Sidekiq — Ruby standard.
Celery — Python standard, with Redis/RabbitMQ/SQS.
Temporal — durable execution. Replaces cron + retry + state machines.
Inngest / Trigger.dev — TS-friendly serverless job runners.
pgmq — Postgres message queue when you want to avoid Redis.

Temporal is the 2025 pick for complex multi-step workflows.

12. Deployment — runtime + framework combos that "just work"

Vercel + Next.js (or Hono) — zero-config, edge-friendly.
Cloudflare Workers + Hono — lowest global latency.
Railway / Render / Fly.io — container-style deploy for traditional frameworks.
AWS Lambda + FastAPI (Mangum) / Spring Boot (GraalVM) — enterprise serverless.
Kubernetes + anything — large teams, regulated environments.
Bun + Elysia + Bun Deploy (2025) — newcomer watching.

13. Decision tree

Q1: Edge/serverless target?
├─ Yes: Hono (edge), Elysia (Bun), FastAPI (Lambda), Quarkus (native)
└─ No → Q2

Q2: TS monorepo, FE/BE tight?
├─ Yes: Next.js API / tRPC / Hono
└─ No → Q3

Q3: Enterprise Java/Kotlin, regulated?
├─ Yes: Spring Boot (+ Virtual Threads)
└─ No → Q4

Q4: High throughput / low latency critical?
├─ Yes: Go (Fiber/Echo/Chi) or Rust (Axum)
└─ No → Q5

Q5: Python data/AI-adjacent?
├─ Yes: FastAPI / Litestar
└─ No: NestJS or Fastify

12-item adoption checklist

Team language/runtime strengths mapped?
Cold-start budget defined?
Type sharing with frontend planned?
OpenAPI or schema source-of-truth picked?
ORM chosen considering scale/migrations?
Background job runner chosen?
Auth library decided (self-host vs managed)?
Observability stack integrated from day 1?
Rate limiting / abuse prevention layered in?
Local dev matches prod (Docker/Bun/Node parity)?
Testing strategy — unit + integration + contract?
Deployment pipeline automated, rollback tested?

10 common anti-patterns

Picking NestJS for a 500-line service "just in case."
Using GraphQL when 3 REST endpoints would do.
Ignoring cold-start on serverless — big framework + heavy DI.
Shared schemas stolen from frontend types (drift hell).
No schema validation at the edge (all errors surface as 500 later).
ORM lazy-loading in a loop — N+1 becomes 1000+1.
Long-lived DB connections in Lambda — connection storm.
Auth rolled from scratch — mistakes will happen.
No OpenAPI → no client codegen → manual fetch calls everywhere.
Deploying to Kubernetes "because we have Kubernetes" — often overkill.

Next episode

S7 E3 — Distributed Databases 2025: CockroachDB, Spanner, TiDB, Yugabyte, Aurora DSQL, Neon, PlanetScale, Turso, D1. How to pick, not a "best of."

— End of Modern Backend Frameworks.