Why I Switched from REST to tRPC in My FullStack Projects

When I first started building fullstack apps with Next.js, I was writing REST APIs the traditional way creating route handlers, defining request/response types manually, and hoping my frontend and backend stayed in sync.

Then I discovered tRPC, and it changed everything.

The Problem with REST

Every time I added a new endpoint, I had to:

Define the route handler

Create TypeScript types for the request and response

Make sure the frontend fetched with the correct types

Maintain two separate sources of truth

Enter tRPC

With tRPC, your API contract is defined once and shared automatically. You write your server procedures, and the client knows exactly what's available, what arguments it expects, and what it returns all at compile time.

My Takeaway

For solo developers and small teams building TypeScript fullstack apps, tRPC is a gamechanger. It's not for every project (public APIs still need REST/GraphQL), but for internal APIs, it's hard to beat.