← Back to Blog

tRPC vs. REST: Is Type-Safety the New Standard for APIs?

10/27/2025•4 min read

REST has dominated web APIs for decades, but tRPC is winning developers with its simple, end-to-end type-safety. Is it time to ditch JSON endpoints for TypeScript inference? Let’s compare.

What is a REST API?

For decades, REST (Representational State Transfer) has been the undisputed king of web APIs. It's an architectural style, not a formal protocol, that uses standard HTTP methods to interact with data.

You've seen it a thousand times:

  • GET /api/users to fetch a list of users.
  • GET /api/users/123 to fetch a single user.
  • POST /api/users to create a new user.
  • DELETE /api/users/123 to remove a user.

It's simple, stateless, and platform-agnostic. It works with any language, and its data format (usually JSON) is universally understood.

JSON data on a screen

JSON data on a screen

The "Problem" with REST

REST's greatest strength—its loose coupling—is also its biggest weakness in modern, full-stack applications.

The client (your React/Vue/Svelte app) and the server (your Node.js/Python/Go backend) are completely disconnected.

  • The server has no idea what data the client actually needs.
  • The client has no idea what the shape of the server's data is.

This leads to common developer pains:

  1. Manual Type Definitions: You have to manually define your User type in TypeScript on the server... and then again on the client.
  2. Runtime Errors: If the backend team renames user.name to user.fullName, the client-side app breaks, and you only find out at runtime (or from an angry user).
  3. Over/Under-fetching: GET /api/users might send 50 fields per user when your app only needs to display their name.

What is tRPC?

tRPC (TypeScript Remote Procedure Call) is a lightweight library that solves these problems by enabling end-to-end type-safety between a TypeScript client and server.

It is not a new protocol. It's not a replacement for HTTP. It's a smart convention that uses TypeScript's inference to make your API feel like you're just... calling a function.

How it works:

  1. Define a "Router" (Server): On your server, you define functions inside a tRPC router. This is your single source of truth.
  2. Export the Type (Server): You export the type of your router, not the router itself.
  3. Import the Type (Client): Your client (e.g., React app) imports that one type.
  4. Call Functions (Client): The tRPC client hook now has full auto-completion and type-checking based directly on your server-side router.

If you change a function name on the server, your client-side code will immediately show a TypeScript error in your VS Code. No more runtime surprises.

TypeScript code on a monitor

TypeScript code on a monitor

When to Use tRPC

tRPC shines in specific scenarios:

  1. Full-Stack TypeScript Apps: This is its sweet spot. Think Next.js, SvelteKit, or any project where you control both the frontend and backend, and both are written in TypeScript.
  2. Monorepos: When your client and server code live in the same repository, sharing types is effortless.
  3. Indie Devs & Small Teams: The development speed is incredible. You can refactor and build features with confidence, knowing TypeScript has your back.
  4. Internal Tools: Perfect for building admin dashboards or internal applications where you don't need a public-facing, language-agnostic API.

When to Stick with REST

tRPC is not a silver bullet. REST remains the right choice for:

  1. Public APIs: If you need to expose your data to third-party developers, they won't be using TypeScript. REST is the lingua franca of the web.
  2. Microservices: When you have many small services, potentially written in different languages (Go, Python, Rust), REST is the standard for communication.
  3. Strict Decoupling: If your frontend and backend teams are completely separate organizations that must evolve independently, a formal, language-agnostic contract like REST (or GraphQL) is better.
  4. Heavy Caching Needs: REST's adherence to HTTP standards makes it trivial to cache at the HTTP level (CDNs, reverse proxies).

Charts and graphs on a screen

Charts and graphs on a screen

Final Thoughts

tRPC isn't a "REST killer." It's a new, specialized tool for a modern problem.

  • REST is like a shipping container. It's standardized, universal, and can carry anything, but it's a bit clunky to pack and unpack.
  • tRPC is like a direct pipeline between two buildings you own. It's custom-built, incredibly fast, and perfectly efficient... but it only works for you.

The choice is simple:

  • Building a public-facing API or for a polyglot (multi-language) system? Use REST.
  • Building a full-stack TypeScript application and want the best possible developer experience? Use tRPC.