tRPC vs REST

tRPC and REST take opposite approaches to the API boundary. REST treats the network as a clear separation — client and server communicate through a well-defined HTTP interface. tRPC erases the boundary, making server functions callable from the client with full TypeScript type inference.

The Type Safety Revolution

tRPC's killer feature is end-to-end type safety without code generation. When you change a server procedure's return type, the client immediately sees a TypeScript error. Rename a field, and your IDE highlights every affected call site across the full stack.

With REST, keeping client and server types in sync requires either manual effort or a code generation pipeline (OpenAPI to TypeScript). Both approaches introduce friction that tRPC eliminates.

The Trade-Off: Flexibility vs Safety

tRPC's type safety comes at a cost — it locks you into TypeScript on both sides. You cannot expose a tRPC API to a mobile team writing Swift, a partner team using Python, or a public developer community. REST's language-agnostic HTTP interface has no such constraint.

When tRPC Shines

tRPC is transformative for full-stack TypeScript applications. A Next.js app with a tRPC backend feels like calling local functions — autocomplete works across the network boundary, refactoring is fearless, and runtime type mismatches vanish.

For internal tools, admin dashboards, and MVPs where one team owns both client and server, tRPC eliminates an entire class of bugs and boilerplate.

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

The Bottom Line

Use tRPC for TypeScript monorepos where one team owns the full stack. Use REST when you need language-agnostic interoperability, public APIs, or HTTP caching infrastructure.