GraphQL was the future of APIs in 2019. By 2026, the picture is more nuanced. Shopify, GitHub, and Twitter built public GraphQL APIs. Netflix, Airbnb, and many others adopted it internally. But the operational complexity — schema management, N+1 query problems, resolver performance, caching difficulty — led a wave of teams to step back.
REST remains dominant for public APIs. The HTTP ecosystem (caching, CDNs, curl, browser devtools, OpenAPI tooling) is unmatched. If your API is public, REST is the path of least resistance. OpenAPI 3.1 + TypeScript type generation covers the type-safety gap that drove teams to GraphQL.
GraphQL wins when your clients have divergent data requirements. A mobile app needs 3 fields from a User. A web dashboard needs 20. With REST, that's either two endpoints or over-fetching. With GraphQL, both clients query exactly what they need. Facebook, with 2B+ users across radically different clients (web, iOS, Android, low-bandwidth markets), is the canonical case.
tRPC is the best choice for TypeScript full-stack teams where the client and server are in the same monorepo. End-to-end type safety with zero schema generation, no codegen step, and minimal runtime overhead. It's not a public API solution — it tightly couples client and server — but for internal Next.js/Remix apps, it's faster to develop than either REST or GraphQL.
gRPC is the right choice for service-to-service communication where performance matters. Proto files as the contract, binary serialization, streaming support. Poor browser support limits it to backend services.
The 2026 default: REST + OpenAPI for public APIs, tRPC for TypeScript full-stack, gRPC for internal services, GraphQL only when you have the divergent client requirement that justifies the complexity.