Welches Problem tRPC löst

Wenn Sie eine REST-API in TypeScript erstellen, definiert der Server die Antwortstruktur. Auf dem Client müssen Sie passende TypeScript-Typen manuell erstellen. Diese Typen driften im Laufe der Zeit auseinander, wenn sich die API weiterentwickelt, und der Compiler kann die Abweichung nicht erkennen, weil die Typen in separaten Paketen definiert sind.

Ein umbenanntes Feld auf dem Server wird auf dem Client zu einem stillen Laufzeitfehler.

GraphQL löst Typabweichungen, indem es TypeScript-Typen aus dem Schema generiert, etwa mit Tools wie graphql-codegen. Das funktioniert gut, bringt aber zusätzliche Komplexität mit sich: eine separate Abfragesprache (GraphQL SDL), einen Codegenerierungsschritt in der Build-Pipeline und Werkzeuge zur Schemaverwaltung.

Für Teams, die bereits in GraphQL investiert haben, ist Codegen die richtige Lösung. Für Teams, die Typsicherheit ohne den GraphQL-Overhead wünschen, bietet tRPC eine Alternative.

Der Ansatz von tRPC ist radikal einfach: Definieren Sie Ihre API-Prozeduren auf dem Server als TypeScript-Funktionen, exportieren Sie den Router-Typ und importieren Sie diesen Typ auf dem Client. Keine Codegenerierung. Keine separate Schemasprache.

Der TypeScript-Compiler selbst setzt den Vertrag zwischen Client und Server zur Build-Zeit durch.

tRPC setzt voraus, dass Server und Client Typen über TypeScript-Importe gemeinsam verwenden. Das funktioniert in einem Monorepo (Turborepo, Nx, pnpm workspaces) ganz natürlich, in dem Server und Client separate Pakete sind, die voneinander importieren können.

Bei einem vollständig getrennten Backend und Frontend müssten Sie die Router-Typen als gemeinsames Paket veröffentlichen. Das fügt einen Veröffentlichungsschritt hinzu, kommt aber weiterhin ohne Codegenerierung aus.

Auf dem Server definieren Sie einen Router und exportieren seinen Typ: export type AppRouter = typeof appRouter. Auf dem Client importieren Sie diesen Typ und erstellen einen typisierten Client: createTRPCReact(). Der Client kennt genau, welche Prozeduren vorhanden sind und welche Eingabe- und Ausgabetypen sie haben.

Das Umbenennen einer Prozedur auf dem Server führt sofort zu einem TypeScript-Fehler auf dem Client.

Da tRPC das Typsystem von TypeScript direkt verwendet, bietet Ihr Editor auf der Clientseite vollständige Autovervollständigung für Prozedurnamen, Eingabeformen und Rückgabetypen. Das Umbenennen einer Prozedur ist ein TypeScript-Umbenennungs-Refactoring und keine manuelle Suche-und-Ersetzen-Aktion in der gesamten Codebasis.

Diese Verbesserung der Developer Experience ist in der Praxis das am meisten gelobte Feature von tRPC.

Standardmäßig verwendet tRPC HTTP als Transport. Jeder Aufruf einer Prozedur ist eine HTTP-Anfrage. tRPC unterstützt auch WebSockets für Subscriptions. Der Transport ist ein Implementierungsdetail; die Client-API ist unabhängig vom Transport identisch.

Sie können tRPC-Prozeduren außerdem mit dem REST-Adapter als herkömmliche REST-Endpunkte bereitstellen, um die Kompatibilität mit Clients zu gewährleisten, die nicht tRPC verwenden.

tRPC funktioniert als Middleware in Express, Fastify und Hono. Für Next.js integriert es sich über API-Route-Handler. Das Starterprojekt create-t3-app (T3 Stack) bündelt tRPC, Prisma, NextAuth und Tailwind zu einem Full-Stack-Next.js-Template.

Der T3 Stack ist der beliebteste Ausgangspunkt für tRPC und demonstriert für den Produktionseinsatz geeignete Muster.

Ein weiterer typsicherer REST-Ansatz besteht darin, Zod-Schemas zu definieren, automatisch eine OpenAPI-Spezifikation zu generieren und aus der Spezifikation TypeScript-Typen zu erzeugen. Dadurch erhalten Sie einen API-Vertrag, den Clients ohne TypeScript konsumieren können.

tRPC ist einfacher, aber auf TypeScript beschränkt. OpenAPI+Zod bringt Komplexität hinzu, erzeugt aber einen öffentlichen API-Vertrag. Wählen Sie tRPC für die interne Kommunikation zwischen TypeScript-Systemen; wählen Sie OpenAPI für öffentliche APIs.

tRPC ist kein Ersatz für REST, wenn Sie eine öffentliche API benötigen, die von Drittanbietern, mobilen Clients ohne TypeScript oder Partnern mit Bedarf an einem stabilen versionierten Vertrag genutzt wird. tRPC ist speziell für TypeScript-Monorepos mit typsicherem Full-Stack-Ansatz gedacht.

Das Verständnis dieses Geltungsbereichs verhindert, dass Sie tRPC in Kontexten einsetzen, in denen REST oder GraphQL besser geeignet ist.

Das Ausführen von npm create t3-app@latest erstellt das Grundgerüst eines Next.js-Projekts mit vorkonfiguriertem tRPC, Prisma, NextAuth.js, Tailwind CSS und TypeScript. Der generierte Code veranschaulicht die Router-Struktur, die Erstellung des Kontexts und die Einrichtung des Clients.

Das Studium dieses Grundgerüsts ist der schnellste Weg zu verstehen, wie alle tRPC-Bestandteile in einer echten Anwendung zusammenspielen.

Wie gibt tRPC Typen zwischen Server und Client weiter, ohne Codegenerierung?

tRPC verhindert, dass die Typen zwischen TypeScript-Client und -Server auseinanderlaufen, indem der TypeScript-Typ des Routers direkt per Import gemeinsam genutzt wird. Dadurch entfällt die Codegenerierung. Es funktioniert in Monorepos und lässt sich in Next.js, Express, Fastify und Hono integrieren. Der T3 Stack (create-t3-app) ist der etablierte Starter für produktive Anwendungen.

tRPC ist ausschließlich für TypeScript ausgelegt und eignet sich am besten für interne Full-Stack-Anwendungen, nicht für öffentliche APIs.