In a World of Hype, GraphQL's Fundamental Advantages Over tRPC Still Hold True
It seems like tRPC is all the rage these days, and I get it. The promise of end-to-end type safety with minimal boilerplate code is compelling, especially for teams working within a TypeScript monorepo. It solves a real problem and makes for a great developer experience. But as a software engineer who’s been in the trenches, I can’t help but feel that the current hype often overlooks some significant disadvantages.
For me, GraphQL still holds a powerful and often misunderstood advantage that goes beyond the language-agnostic nature of its APIs. While that’s a huge benefit for cross-platform teams, my work is primarily web-focused, so I’m more interested in what it offers within a single application.
The core advantage, in my opinion, is the ability to customize queries on the client. With tRPC, the API is essentially a collection of predefined function calls. The server dictates what data you can fetch with each call. While you get type safety, you lose flexibility.
If a new UI component needs a slightly different subset of data, you often have to modify the server-side resolver or create a new one entirely. This tight coupling between the client and server can lead to over-fetching or under-fetching and makes the frontend team dependent on the backend team for every minor data requirement change.
