Picking an API style in 2026 used to be three religious wars. The dust has mostly settled — each approach has a clear sweet spot, and the right answer depends primarily on who consumes the API and how. This piece is the framework for picking, with the patterns that show up in real production stacks and the trade-offs nobody mentions in the launch posts.
What changed in 2026
- tRPC v11 ships with stable subscriptions, server-sent events, and Server Component integration — closing the last gaps to GraphQL on real-time and React.
- GraphQL Federation v2 and tools like Apollo Router, Hive, and WunderGraph made federated GraphQL operationally tractable for the first time.
- OpenAPI 3.2 + typed clients (openapi-fetch, hey-api) brought REST APIs close to GraphQL/tRPC's type-safety advantages.
When tRPC wins
- Internal full-stack TypeScript app. Frontend and backend are the same codebase or share types.
- Single team owning both ends. No need for a versioned public contract.
- Speed of iteration matters more than long-term consumer stability.
- Best DX in the category — autocomplete across the wire, no codegen step.
Limitation: TypeScript-only. The "no schema" pitch becomes "no inter-language contract" if you have non-TS consumers.
When GraphQL wins
- Public API with many different consumers who want different data shapes.
- Mobile + web + partners all reading the same data, requesting different slices.
- You need real-time (subscriptions) and a strong schema-first culture.
- You're at scale with a federation story (multiple teams owning different schema chunks).
Limitation: operationally heavier than REST or tRPC. Caching, N+1, persisted queries — all real considerations.
When REST wins
- Public API consumed by unknown clients.
- Language-agnostic surface — mobile native, embedded, partners in random languages.
- You want HTTP caching (CDN, browser) to do the heavy lifting.
- Standard tooling (Postman, curl, OpenAPI) matters for your consumers.
Limitation: type safety requires discipline (OpenAPI + generated clients). Over- or under-fetching is the historic complaint.
Comparison
| Dimension |
tRPC |
GraphQL |
REST |
| Type safety |
Inferred (best) |
Schema-first |
OpenAPI (good) |
| Best client |
TS web/server |
Diverse |
Polyglot |
| Caching |
Limited |
App-level |
HTTP-native |
| Real-time |
SSE/WS |
Subscriptions |
SSE/WS |
| Setup overhead |
Lowest |
Highest |
Low |
| Iteration speed |
Highest |
Medium |
Medium |
| Best for |
Internal full-stack TS |
Public diverse consumers |
Public any consumer |
The hybrid that wins
A surprising number of 2026 stacks use two:
- tRPC for internal app (web → API server in the same monorepo).
- REST or GraphQL public layer for third-party consumers, mobile apps, partners.
This is the right answer for many apps: ergonomic internal speed plus a versioned, stable external surface.
What about gRPC?
gRPC remains the best choice for service-to-service communication inside a microservices architecture. Strong types, fast binary protocol, streaming. Not consumer-facing usually — but where it fits, it dominates. ConnectRPC is the modern wrapper that makes it browser-friendly.
Picking guide
- Building a SaaS with a React frontend and TS backend, no external API yet → tRPC.
- Public API for developers (Stripe-style) → REST + OpenAPI.
- App with mobile + web + partners reading the same data → GraphQL.
- Inter-service communication at scale → gRPC / ConnectRPC.
- Edge-first app on Cloudflare Workers → REST or tRPC v11.
What to skip
- GraphQL for a tiny single-consumer app. The setup cost rarely pays off below a clear schema-need.
- REST without OpenAPI in 2026. The type-safety gap to the alternatives is real and unnecessary.
- tRPC for public APIs — the lock-in to TypeScript-on-both-ends is a real consumer constraint.
FAQ
Can tRPC do real-time?
Yes — v11 supports SSE and WebSocket subscriptions natively.
Is GraphQL slower than REST?
Not inherently. Most "GraphQL is slow" complaints trace to N+1 queries (solved with DataLoader) or missing caching (solved with persisted queries).
REST + OpenAPI vs tRPC for internal apps?
tRPC's DX is meaningfully better if your stack is TS end-to-end. OpenAPI + generated clients close the gap for polyglot teams.
Should I migrate from REST to GraphQL?
Probably not unless you have a concrete consumer pain (over-fetching, multiple aggregations). Stable REST APIs are valuable.
Where to go next
For related material see Server Components vs Server Actions in 2026, Bun vs Deno vs Node in 2026, and TypeScript strict mode guide in 2026.