tRPC: The End of API Docs as We Know Them

TRPC v11, a TypeScript Remote Procedure Call framework, eliminates the need for REST endpoints, OpenAPI specs, and manual type synchronization by allowing developers to write TypeScript functions on the server that are callable from the frontend with full type inference. The framework, stable since early 2026, introduces support for React Query v5 with Suspense, Server-Sent Events for real-time features, native FormData and File handling, and router-level code-splitting. A developer who built the same CRUD app with tRPC, REST plus Zod, and GraphQL reported zero type mismatches with tRPC over three weeks, compared to two with REST and one with GraphQL.

tRPC stands for TypeScript Remote Procedure Call. The pitch is simple: instead of writing REST endpoints, writing OpenAPI specs, generating TypeScript types from those specs, then manually keeping all that in sync — you just write TypeScript functions on the server. tRPC makes them callable from the frontend with full type inference. No code generation. No duplicating schemas. Your backend code is the API. Here's what that actually looks like: js // server/router.ts export const appRouter = t.router { getUserById: t.procedure .input z.string .query { input } = { return db.user.findUnique { where: { id: input } } ; } , } ; // client/UserProfile.tsx const user = trpc.getUserById.useQuery "user 123" ; // user.data has the Prisma User type — you didn't write a single type annotation Look at what's not there. No URL paths, no HTTP methods, no duplicating your types on both sides. Change the backend return and your IDE finds every broken frontend reference before you hit save. V11 has been stable since early 2026. If you're still on v10, here's what you get: This is the biggest one. V11 requires React Query v5, which means Suspense support is baked in: function UserProfile { userId }: { userId: string } { const user = trpc.user.get.useSuspenseQuery { id: userId } ; return <h1 {user.name}</h1 ; } No isLoading checks. No data?.name everywhere. Wrap it in Suspense + ErrorBoundary and you get clean, declarative data fetching. V10 locked you into WebSocket for real-time features. V11 adds Server-Sent Events via the httpSubscription link, which means live chat, dashboards, and notifications without managing WebSocket connections. Also works with serverless platforms like Vercel and Cloudflare — which WebSocket never handled well. V11 handles FormData, Blob, File, and Uint8Array natively. If you've been splitting your project into "tRPC for queries" and "separate REST endpoint for uploads" — that workaround is dead. Everything goes through the same layer now. Big projects used to pay the bundle cost for all routers upfront. V11 supports code-splitting at the router level: js const adminRouter = = import './routers/admin' ; // Only loads when admin feature is accessed After building with tRPC for about a year, here's where it genuinely makes sense: TypeScript monorepos. If your frontend and backend share a repo — which they do with Next.js, SvelteKit, Remix — tRPC eliminates the type boundary. There's no "frontend types" vs "backend types." It's just types. Internal tools. Speed beats discoverability here. You're iterating fast, changing endpoints constantly, and the whole team knows TypeScript. tRPC matches how you actually work. Server-first frameworks. tRPC with Next.js App Router or SvelteKit server load functions gives you type safety from the database query straight to your React component. Hard to beat that developer experience. Look, tRPC isn't here to kill REST or GraphQL. Anyone telling you otherwise is overselling it. Public APIs are a bad fit. If mobile apps or third-party services need to call your API, tRPC isn't the right tool. It only works with TypeScript clients that import your router types. Non-TypeScript consumers? Can't use it. Polyglot teams. If your backend has Python, Go, or Rust services alongside TypeScript, tRPC doesn't help. It's TypeScript end-to-end or nothing. Heavy caching. REST has built-in HTTP caching ETag, conditional GETs, CDN-friendly URLs that tRPC can't match. If caching is your main concern, REST still wins. I built the same CRUD app with tRPC, REST + Zod, and GraphQL to compare. Response times were within 10-15% of each other for simple queries. The real difference? Over three weeks of active development, tRPC had zero type mismatches. REST+Zod had two. GraphQL had one caught by codegen . Tiny sample, but it lines up with my broader experience. REST still rules for public APIs. GraphQL still wins when clients need flexible queries. tRPC wins when you're all-in on TypeScript and want the fastest possible feedback loop. If your next project is a TypeScript monorepo — a Next.js SaaS, an internal dashboard, a SvelteKit app — yes. V11 is mature. The ecosystem is stable. You'll save real time not maintaining a separate type layer. You can always add a REST or OpenAPI layer on top later. If you're building a public API or serving non-TypeScript clients, stick with REST or GraphQL. You're not missing anything. The thing about tRPC is this: it doesn't replace API design. It removes the translation layer between your backend and frontend. For teams already living in TypeScript, that removal is worth more than I thought before I tried it. This article is based on my original post at auraimagai.com, where I write about TypeScript, full-stack development, and tools that actually change how you build.