REST, RPC and GraphQL, on constraints

REST is resource-shaped. It suits domains where nouns are stable and clients want the same things repeatedly, and it gets you HTTP caching, conditional requests and a URL space people can explore for free. Its cost is round trips and over-fetching: a screen that needs a user, their orders and each order status is three or four calls that nobody can collapse.

RPC, including tRPC and gRPC, is verb-shaped. You call a function, typed end to end, and there is no debate about whether cancelling an order is a DELETE or a POST. It suits an internal service or a single-team full-stack app where client and server ship together. The cost is that you lose the free HTTP layer and you have coupled a client build to a server build.

GraphQL lets the client specify the shape of the response, which is genuinely the right answer when you have many clients with different screens and a deeply connected graph. The cost is real and often underestimated: caching becomes yours to solve rather than the CDN's, arbitrary queries make performance unpredictable, and you will implement dataloader batching to fight the N+1 that the flexibility creates. Choose it when you have the problem it solves, and not before.