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

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.

---

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.

---

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).

---

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.