GraphQL vs REST vs tRPC: Choosing an API Style in 2025

The API debate is no longer “REST or GraphQL?”. tRPC and bidirectional streaming via gRPC-Web have entered the chat. Here is how to decide.

REST

• HTTP verbs + resources. Universally understood.
• Pairs naturally with HTTP caching and CDNs.
• OpenAPI 3.1 covers schema, code generation and mocking.

Pick REST when: your API is consumed by many unknown clients (public APIs), or you rely heavily on HTTP cache semantics.

GraphQL

• Single endpoint, typed schema, clients pick fields.
• Solves over-fetching for diverse clients (mobile + web + partners).
• Operational cost is real: query complexity, N+1, persisted queries, caching.

Pick GraphQL when: many heterogeneous clients pull overlapping data, and you have the team capacity to operate it well.

tRPC

• TypeScript end-to-end with no codegen. Server functions imported on the client.
• Tiny runtime, excellent DX inside a TS monorepo.
• Not a wire protocol — it is a TS abstraction over JSON-over-HTTP.

Pick tRPC when: server and client are both TypeScript and live in one repo (Next.js, Remix, SvelteKit + tRPC adapter).

Comparison table

Concern	REST	GraphQL	tRPC
Cross-language clients	excellent	excellent	poor (TS-only)
Type safety	OpenAPI codegen	schema codegen	inferred, instant
HTTP caching	great	requires work	great
Over-fetching	possible	solved	solved
Operational complexity	low	high	low

You can mix

Use REST for public webhooks, GraphQL for the SPA, and tRPC inside the admin panel. The contract style should follow the consumer, not the other way around.