The Question Nobody Asks
Every comparison of GraphQL vs REST vs tRPC focuses on technical merits — type safety, bandwidth efficiency, tooling. That's fine for a tech talk, but it misses the most important factor: who's building it, and who's consuming it? After shipping APIs in all three paradigms across a dozen projects, we've found that team structure is the strongest predictor of which approach works best.
REST: When Your API Has External Consumers
If your API is consumed by third parties — mobile apps from different teams, partner integrations, public APIs — REST is still the default choice. Not because it's technically superior, but because every developer in the world knows how to consume a REST API. The tooling ecosystem (Postman, Swagger/OpenAPI, API gateways) is mature and battle-tested.
We use REST with OpenAPI spec generation (via Zod schemas validated at runtime) for all our client-facing APIs. The spec is auto-generated from the code, which means the documentation is always accurate. We host it on Swagger UI, and our clients' integration teams can start consuming the API within hours of getting access. Try doing that with tRPC.
REST's weakness is the classic over-fetching/under-fetching problem. But in practice, for 90% of CRUD applications, this doesn't matter. Your /users endpoint returns the user object. If you need partial fields, add a ?fields=name,email parameter. GraphQL solves this problem more elegantly, but "more elegant" doesn't always mean "better for your team."
GraphQL: When Frontend Teams Need Autonomy
GraphQL shines when your frontend team is separate from your backend team and needs to iterate on data requirements without waiting for backend changes. We used GraphQL on a large e-commerce project where three frontend teams (web, iOS, Android) consumed the same backend. Each team could query exactly the data they needed without backend coordination. The iOS team needed a different shape of product data than the web team? They just wrote a different query. No backend tickets, no API versioning, no waiting.
The cost: GraphQL is complex to operate. N+1 query problems will destroy your database if you don't implement DataLoader correctly. Authorization is trickier than REST because you need field-level permissions. Caching is harder because you can't use HTTP caching as effectively. Rate limiting is complicated because every request is a POST to the same endpoint. We burned a full sprint on performance optimization for the e-commerce GraphQL API that we wouldn't have needed with REST.
Our honest take: unless you have multiple consumer teams or genuinely complex data relationships, GraphQL is overkill. The setup cost and operational complexity aren't worth it for a single frontend consuming a single backend.
tRPC: When It's One Team, Full-Stack TypeScript
tRPC is our favorite for projects where a single team owns both frontend and backend, and everything is TypeScript. The developer experience is incredible — you get full end-to-end type safety with zero code generation, zero schema definition, and zero serialization bugs. When you change a backend function signature, the frontend gets a TypeScript error immediately. This catches entire categories of bugs at compile time.
We used tRPC on a SaaS dashboard project and the development velocity was noticeably faster than equivalent REST projects. No API documentation to maintain (the types are the documentation), no serialization/deserialization bugs, and the autocomplete in VS Code makes discovery trivial.
The limitation: tRPC only works in the TypeScript ecosystem. If you ever need to expose your API to a non-TypeScript consumer (a Python service, a mobile app, a third-party integration), you'll need to layer REST or GraphQL on top. We had exactly this situation when a client wanted to add a React Native mobile app six months after we'd built a tRPC-powered web app. We ended up running tRPC for the web and a separate REST API for mobile, which defeated the purpose.
Our Decision Framework
One full-stack TypeScript team? tRPC. Multiple consumer teams or complex data graphs? GraphQL. External API consumers or mixed technology stack? REST. When in doubt? REST. It's boring, everyone understands it, and it's never the wrong choice — just sometimes not the optimal one.