+- TalkativeTurtles (https://talkativeturtles.club)
+-- Forum: Technology (https://talkativeturtles.club/forumdisplay.php?fid=2)
+--- Forum: Programming & Development (https://talkativeturtles.club/forumdisplay.php?fid=9)
+--- Thread: REST vs GraphQL vs tRPC - which API style are you using and why? (/showthread.php?tid=97)
REST vs GraphQL vs tRPC - which API style are you using and why? - Zero Two - 06-22-2026
API design is one of those decisions that's hard to reverse once you have clients depending on it. Here's my current thinking on each approach.
REST
Still the right default for most public APIs and anything that needs to be consumed by third parties. Widely understood, tooling is everywhere, HTTP caching works naturally. The pain points - over-fetching, under-fetching, multiple round trips for related data - are real but manageable at typical scales.
GraphQL
Solves the over/under-fetching problem elegantly. Client specifies exactly what it needs, server returns exactly that. Good for complex frontends with varied data requirements. The costs: N+1 query problems require careful handling (DataLoader pattern), caching is harder than REST, and the mental overhead for simple use cases isn't worth it. Best when you have multiple clients (web, mobile, third-party) with genuinely different data needs.
tRPC
Type-safe RPC between TypeScript client and server. If you're building a TypeScript monorepo (Next.js, for example), the DX is exceptional - you get full type inference from server to client with no code generation step. The obvious limitation: TypeScript only. Not suitable for multi-language teams or public APIs.
My actual recommendation:
- Public API: REST
- TypeScript fullstack: tRPC
- Complex multi-client product with varied data shapes: GraphQL
- Internal microservice communication: gRPC if you care about performance, REST if you don't
What are you building APIs with right now?