tRPC vs GraphQL

tRPC and GraphQL both improve on REST for frontend-backend communication, but they make different trade-offs. tRPC optimizes for TypeScript developer experience with zero-codegen type safety. GraphQL optimizes for client flexibility with a language-agnostic query language.

The Developer Experience Gap

tRPC's killer feature is that types flow from server to client through TypeScript inference alone. No code generation step, no schema file, no build pipeline. Change a server procedure and your IDE immediately highlights every affected client call.

GraphQL achieves similar type safety, but it requires a code generation pipeline: define the schema, write queries, run codegen, import generated types. This works well but adds a build step and maintenance overhead.

The Flexibility Gap

GraphQL's killer feature is client-driven queries. A mobile client can request just { user { name avatar } } while a desktop dashboard requests { user { name avatar email orders { total items { name } } } }. The server does not need separate endpoints.

tRPC procedures return fixed shapes. If different clients need different data, you either create multiple procedures or return everything and let clients ignore unused fields.

The Scale Question

GraphQL shines at organizational scale: Apollo Federation lets teams own their portion of the schema independently. tRPC is designed for monorepo workflows where one team owns both sides.

Explore more API patterns in our concepts library and system design interview guide. See pricing for premium access.

The Bottom Line

Use tRPC for TypeScript monorepos with small teams. Use GraphQL when you need client-driven queries, multi-language support, or federated schemas across teams.