Moving from REST to tRPC — Type-Safe APIs Without the Boilerplate

I deleted my entire /routes folder last week. Forty-seven endpoints. Gone. Replaced them all with seventeen lines of tRPC. My teammate asked: Wait, where is the API? I showed him. Same functionality. Same response times. One-tenth the code.

That is when I knew: REST is dead. Long live tRPC.

What Wrong With REST

I have built REST APIs for five years. I know the pain: endpoint/GET, endpoint/POST, endpoint/PUT, endpoint/DELETE everywhere. Forty-seven files that look identical. Types that never match between client and server. Got undefined errors in production I can not reproduce locally. Every endpoint is the same boilerplate. Over and over.

The fundamental problem: REST does not share types. Each endpoint is its own contract. That is forty-seven opportunities for mismatch.

Enter tRPC

tRPC solves this: TypeScript to TypeScript. Your API is your type. Your client knows exactly what the server returns. Instead of forty-seven files, seventeen lines. The procedure contains: logic + validation + type. All in one place. All type-safe.

I migrated my main API in three hours. Three. The migration: Create tRPC router, map existing handlers, update client imports. The result: Zero type errors. Compile-time validation. Runtime confidence.

The tradeoffs: tRPC requires TypeScript. You need to be all-in on types. If your team does not use TypeScript, this is not for you. Some features need work: file uploads, WebSockets, certain REST patterns.

However: For most web apps, it is faster to build and safer to maintain. Three hours to migrate. Forty-seven endpoints. Seventeen lines. That is the ratio. REST served us well. tRPC serves us better.

Try it on one endpoint. See the difference. Then decide.