REST vs GraphQL vs tRPC
Head-to-head comparison of REST, GraphQL and tRPC — architecture, tooling, and when each one is the right pick.
Three API styles, three very different bets on where complexity lives. The right pick depends less on what's trendy and more on who consumes your API.
One-sentence summaries
- REST — resource-oriented HTTP endpoints. Universal, boring, still the safe default for public APIs.
- GraphQL — a single endpoint, a typed schema, clients ask for exactly the fields they need.
- tRPC — no schema, no code-gen; server functions typed end-to-end via TypeScript. Only makes sense if the client is also TS.
Compared on the axes that matter
| Axis | REST | GraphQL | tRPC |
|---|---|---|---|
| Learning curve | Low | Medium | Low (if TS) |
| Client language support | Any | Any | TS only |
| Over/under-fetching | Common | Solved | Solved (per procedure) |
| Caching | HTTP-native | App-level | App-level |
| Schema evolution | Versioning | Deprecation via directives | TypeScript refactor |
| Best for | Public APIs, multiple clients | Complex product surfaces | Internal T3-style monorepos |
Decision rules
- Public API consumed by unknown third parties → REST + OpenAPI.
- Mobile app plus web app sharing one backend, deep object graphs → GraphQL.
- TypeScript monorepo with Next.js / SvelteKit / React Native, no need for non-TS clients → tRPC.
Common myths
- "GraphQL is slower than REST." Not intrinsically — a well-designed GraphQL schema with DataLoader is often fewer DB calls than a naive REST resource fetch.
- "tRPC doesn't scale." tRPC procedures compile to plain HTTP calls; the scaling story is identical to REST.
- "REST is dead." REST powers most of the world's APIs and will for the next decade. It's boring on purpose.
The API style is a means to an end. Pick the one your team can maintain calmly at 4 AM.