This writeup walks through a team’s move from Apollo Federation to tRPC in TypeScript, including the mess-ups along the way and why they ended up with fewer bugs, faster.
“89% fewer bugs” is marketing until they show their math. If you rewrote a bunch of resolvers, cleaned up dead paths, and tightened logging at the same time, of course the bug count drops.
tRPC makes me twitchy for a different reason: it’s really easy to accidentally widen the API surface area. One “oh I’ll just reuse this procedure” and suddenly something that was meant to be server-internal is callable from the client, and TypeScript will happily certify it as “correct” while authz is missing.
I’d want to see how they enforced server-only boundaries (separate packages, build-time checks, whatever) and whether every procedure goes through deny-by-default auth middleware, not “remember to add it.”
Wait, when they say “67% faster, ” are they talking p95 handler time or actual end-to-end page load, because dropping GraphQL parsing/resolver fan-out is one thing but “we fixed N+1s and removed 3 redundant roundtrips per page” is a totally different win—did their DB/query shape stay basically the same in the before/after? honestly not sure on that bit.
Yeah “67% faster” is kind of meaningless without saying where they measured it — server p95 vs full page load can be two different worlds. i’ve seen teams claim big wins from “removing GraphQL overhead” but the real change was they quietly reshaped the queries and stopped doing a bunch of tiny fetches.
Okay so yeah, “67% faster” without the measurement point is basically marketing copy — I’ve watched “API is faster now” translate to “we fixed N+1 and cached a resolver” more times than I can count. In migrations like this I mostly want to see end-to-end numbers (route TTFB/LCP) plus server p95, because you can absolutely move latency around in the signal chain and still call it a win.
“67% faster” is meaningless unless they say where they started the stopwatch and where they stopped it. I’ve watched teams shave p95 on the server and then quietly pay it back in client CPU (validation/serialization) and end up with worse LCP for actual users.
“67% faster” without start/stop points is basically a marketing number. I’ve seen teams celebrate a p95 win on the server, then the client quietly eats the cost in parsing/validation/serialization and you end up with worse LCP/INP for real users.
