REST vs GraphQL vs tRPC Isn't Really a Performance Question

Ask what the difference between REST, GraphQL, and tRPC is and most people can recite it. REST has endpoints, GraphQL has one endpoint and a query language, tRPC gives you typed function calls with no schema. All true. Then the interviewer asks which one you'd actually pick for their project, and the recited version runs out.

I made this call for real on my own CMS, so this is the reasoning I use.

The question behind the question

It usually lands as:

"We're starting a new project. Would you go REST, GraphQL, or tRPC, and why?"

It's never really about which is fastest. Wire up any of the three with a sane database -- and a normal amount of traffic -- and you won't feel a performance difference. What they're checking is whether you can weigh the things that actually differ:

• How many different clients hit this API, and do you control all of them
• Who owns the frontend relative to the backend: same person, same team, or a different team entirely
• How much of the stack is TypeScript, end to end
• Whether you need HTTP caching and CDN behavior for free
• How much schema and tooling overhead the team can carry

Pick the tool that wins on the factors that apply, and say which ones you're ignoring and why.

What each one is actually good at

REST

REST's real strength is that it's boring and universal. Every language, every HTTP cache, every proxy, every junior dev already understands it. GET /projects/123 caches at the CDN with zero effort. A third party can integrate against it without your types, your client library, or a schema download.

The cost: over-fetching and under-fetching. The /projects response has fifteen fields and your list view needs three. Or you need the project plus its author plus the author's avatar, and that's three round trips or a custom ?include= param you invented.

GraphQL

GraphQL fixes the fetching problem. The client asks for exactly the fields it wants, nested how it wants, in one request. That pays off when you have many different clients with different data needs, a web app, an iOS app, a public API, and you don't want to ship a new REST endpoint every time one of them needs a slightly different shape.

The cost: you give up easy HTTP caching (it's mostly POST to one URL), you take on a schema, a gateway, resolver code, and the N+1 problem as a permanent tax you have to actively manage.

tRPC

tRPC's whole pitch is: if the client and server are both TypeScript and live in the same repo, why are you serializing a schema at all. You call a server procedure like a local async function and the types flow through automatically. No codegen, no schema file, rename a field and the client stops compiling.

The cost: it only works if you own both ends and they're both TypeScript. No schema means no easy third-party consumers, no non-JS clients, no language-agnostic contract.

The follow-ups they actually ask

"What problem does GraphQL solve that REST doesn't?" Over- and under-fetching across diverse clients. One request returns exactly the tree of data a screen needs, so the client stops making three calls or receiving twelve unused fields.

"How do you handle N+1 in a GraphQL resolver?" Batch and cache per request. A resolver for author on a list of 50 posts fires 50 lookups unless you put a DataLoader (or your ORM's batching) in front, which collects the ids in a tick and does one where id in (...). Worth being able to say the word DataLoader out loud and explain what it does.

"Why tRPC over GraphQL on a full-stack TS project?" You delete an entire layer. No schema to keep in sync, no codegen step, no resolver boilerplate. The contract is the TypeScript types, checked at build. It's strictly less flexible, and for that specific setup that's the point.

What I actually picked, and why

My CMS has a public REST API and a separate admin client. I went REST, not GraphQL or tRPC, for three reasons:

• The public content endpoints get consumed by a separate site I wanted to cache hard at the CDN. REST gives me Cache-Control and edge caching for free. GraphQL would have fought me on that.
• There's no schema-diverse client explosion. It's one public site and one admin app. GraphQL solves a problem I don't have.
• tRPC was tempting since it's all TypeScript, but the public API needs to be consumable by things that aren't my code, so a plain documented REST contract wins.

If the CMS grew a mobile app and a partner API with wildly different data needs, I'd reconsider GraphQL for the read side. That's the honest answer: the choice tracks the shape of the project, and the project's shape changes.

Quick recap

• The choice is about client diversity, ownership, and how much of the stack is TypeScript, not raw speed
• REST: universal, cache-friendly, boring in a good way; over/under-fetches
• GraphQL: exact-shape fetching for many diverse clients; costs you caching, a schema, and the N+1 tax
• tRPC: delete the schema layer entirely, but only if you own both ends and both are TypeScript
• Name the factors you're deciding on out loud, and say what you'd switch to if the project changed shape

Nobody's impressed by "GraphQL is more efficient." They're impressed by "here's the three things I'd weigh, and here's what I picked last time and why."