Problemet som tRPC löser

När du bygger ett REST-API i TypeScript definierar servern svarens struktur. Klienten måste manuellt skapa matchande TypeScript-typer. Med tiden kan dessa typer hamna ur synk när API:et utvecklas, och kompilatorn kan inte upptäcka avvikelsen eftersom typerna är definierade i separata paket.

Ett fält som får ett nytt namn på servern blir ett tyst runtime-fel på klienten.

GraphQL löser typdrift genom att generera TypeScript-typer från schemat med verktyg som graphql-codegen. Detta fungerar bra men ökar komplexiteten: ett separat frågespråk (GraphQL SDL), ett kodgenereringssteg i byggprocessen och verktyg för schemahantering.

För team som redan satsar på GraphQL är codegen rätt svar. För team som vill ha typsäkerhet utan den extra komplexiteten från GraphQL erbjuder tRPC ett alternativ.

tRPC:s tillvägagångssätt är radikalt enkelt: definiera API-procedurerna på servern som TypeScript-funktioner, exportera routertypen och importera typen på klienten. Ingen kodgenerering. Inget separat schemaspråk.

Själva TypeScript-kompilatorn upprätthåller kontraktet mellan klient och server under byggprocessen.

tRPC kräver att servern och klienten delar typer via TypeScript-importer. Detta fungerar naturligt i ett monorepo (Turborepo, Nx, pnpm workspaces), där servern och klienten är separata paket som kan importera från varandra.

För en helt separat backend och frontend behöver du publicera routertyperna som ett delat paket. Det lägger till ett publiceringssteg men kräver fortfarande ingen kodgenerering.

På servern definierar du en router och exporterar dess typ: export type AppRouter = typeof appRouter. På klienten importerar du typen och skapar en typad klient: createTRPCReact(). Klienten vet exakt vilka procedurer som finns och vilka typer deras indata och utdata har.

Om du byter namn på en procedur på servern visas omedelbart ett TypeScript-fel på klienten.

Eftersom tRPC använder TypeScripts typsystem direkt erbjuder editorn fullständig autokomplettering av procedurnamn, indataformat och returtyper på klientsidan. Att byta namn på en procedur är en TypeScript-refaktorering för namnbyte, inte en manuell sökning och ersättning i hela kodbasen.

Denna förbättring av utvecklarupplevelsen är i praktiken tRPC:s mest uppskattade funktion.

Som standard använder tRPC HTTP som transportprotokoll. Varje proceduranrop är en HTTP-förfrågan. tRPC stöder också WebSockets för prenumerationer. Transporten är en implementationsdetalj; klientens API är identiskt oavsett transport.

Du kan också exponera tRPC-procedurer som konventionella REST-slutpunkter med REST-adaptern, för kompatibilitet med klienter som inte använder tRPC.

tRPC fungerar som middleware i Express, Fastify och Hono. För Next.js integreras det via API-rout handlers. Startpaketet create-t3-app (T3 Stack) samlar tRPC, Prisma, NextAuth och Tailwind i en fullständig Next.js-mall för hela stacken.

T3 Stack är den populäraste startpunkten för tRPC och visar mönster som är klara för produktion.

En annan typsäker REST-metod är att definiera Zod-scheman, automatiskt generera en OpenAPI-specifikation och generera TypeScript-typer från specifikationen. Detta ger ett API-kontrakt som klienter som inte är skrivna i TypeScript kan använda.

tRPC är enklare men fungerar endast med TypeScript. OpenAPI+Zod innebär större komplexitet men skapar ett offentligt API-kontrakt. Välj tRPC för intern kommunikation mellan TypeScript-system och OpenAPI för offentliga API:er.

tRPC ersätter inte REST när du behöver ett offentligt API som används av tredjeparter, mobilklienter som inte är skrivna i TypeScript eller partner som behöver ett stabilt versionshanterat kontrakt. Det är specifikt avsett för TypeScript-monorepon med typsäkerhet i hela stacken.

Genom att förstå denna begränsning undviker du att införa tRPC i sammanhang där REST eller GraphQL passar bättre.

Kommandot npm create t3-app@latest skapar grundstrukturen för ett Next.js-projekt med tRPC, Prisma, NextAuth.js, Tailwind CSS och TypeScript förkonfigurerade. Den genererade koden visar routerstrukturen, hur context skapas och hur klienten konfigureras.

Att studera denna grundstruktur är det snabbaste sättet att förstå hur alla tRPC-delar passar ihop i en riktig applikation.

tRPC löser problemet med typdrift mellan TypeScript-klient och server genom att dela routerns TypeScript-typ direkt via import, vilket eliminerar kodgenerering. Det fungerar i monorepon och integreras med Next.js, Express, Fastify och Hono. T3 Stack (create-t3-app) är det standardiserade startpaketet för produktionsapplikationer.

tRPC är endast avsett för TypeScript och passar bäst för interna fullstackapplikationer, inte publika API:er.