A developer spent two weeks swapping a REST API for tRPC in an internal tool.

Why the switch mattered

The old stack forced us to maintain a DTO, a validator, and a separate set of TypeScript types for the frontend. Rename a backend field, and the API still returned 200, the UI kept rendering, and the bug showed up only as “undefined” values. A customer caught the issue before anyone on the team did. REST contracts hid the problem, and the extra files added maintenance that never paid off.

What the REST setup looked like

  • OpenAPI spec – a static file that described endpoints but never served as the source of truth.
  • Client SDK generation step – a CI job that produced a JavaScript wrapper.
  • Postman collection – a shared testing artifact that no one used.
  • Manual TypeScript interfaces – hand-written types that had to stay in sync with the server.

Every API change touched at least three of those artifacts, plus the validator and any downstream fetch calls. The process was error-prone and slow.

How tRPC trimmed the codebase

tRPC eliminates the separate contract file. The server exports a router type; the client imports that same type. Rename a backend field, and the editor flags the mismatch instantly—no code run, no failed request needed. The developer ripped out:

  • The OpenAPI spec file.
  • The client SDK generation step.
  • The unused Postman collection.
  • The folder of manual TypeScript interfaces.

The repo became leaner, and feedback arrived during development instead of after deployment.

Limits of tRPC

tRPC only works when both ends speak TypeScript. It falls short if:

  • A mobile team uses Swift or Kotlin.
  • The API must be consumed by external partners.
  • You need a public, language-agnostic interface.

What the migration actually required

The two-week effort was more than copy-and-paste. The developer had to:

  • Rewrite every fetch call to use tRPC’s client functions.
  • Adjust error-handling logic.
  • Update UI components that relied on loading and retry states tied to raw HTTP responses.

Questions to ask before you go

  • Do both frontend and backend use TypeScript? Without a shared type system, tRPC loses its main advantage.
  • Is the same team responsible for both sides? Ownership gaps can reintroduce contract drift.
  • Are you fixing a concrete bug or chasing a trend? The productivity boost is real, but it should solve an existing pain point.

A hybrid approach for 2025

Many teams find the sweet spot by running both stacks:

  • tRPC for internal application layers where the codebase is wholly TypeScript and the same team owns the server and client.
  • REST for webhooks, public APIs, and partner integrations where language-agnostic access is required.

Using the right tool for each surface keeps internal development fast while preserving the openness needed for external consumers.

Takeaway: Replacing REST with tRPC can eliminate duplicated contract artifacts and surface bugs at edit time, but the gains only materialize when the whole stack shares TypeScript and the team can absorb the migration cost. A mixed strategy lets you reap the benefits without locking out non-TypeScript consumers.