What's the Big Deal?

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:

// 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.

tRPC v11: What Actually Changed

V11 has been stable since early 2026. If you're still on v10, here's what you get:

React Query v5 Integration

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.

SSE Subscriptions

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.

File Uploads (Finally)

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.

Lazy-Loaded Routers

Big projects used to pay the bundle cost for all routers upfront. V11 supports code-splitting at the router level:

const adminRouter = () => import('./routers/admin');
// Only loads when admin feature is accessed

Where tRPC Actually Wins

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.

Where tRPC Falls Short

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.

The Practical Bottom Line

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.

Should You Use tRPC in 2026?

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.