Warte – diese ID steht auf der Verbotsliste. Ich wähle eine andere:
Für TypeScript-Teams, die schlanke API-Architekturen ohne GraphQL-Overhead anstreben, wird tRPC zur ernstzunehmenden Alternative – mit direkter Typinferenz statt Code-Generierung und enger IDE-Integration als Kernversprechen.
tRPC als TypeScript-native Alternative zu Apollo Federation
Was tRPC von Apollo Federation unterscheidet
Apollo Federation ist seit Jahren ein etablierter Standard für die Komposition verteilter GraphQL-Dienste in größeren Organisationen. Der Ansatz bringt jedoch konzeptionellen Aufwand mit sich: Schema-Definitionen, Resolver-Ketten und ein eigener Gateway-Layer erhöhen die Einstiegshürde – besonders für Teams, die primär in TypeScript arbeiten.
tRPC verfolgt einen grundlegend anderen Ansatz. Statt einer separaten Schema-Sprache nutzt das Framework die TypeScript-Typisierung direkt als Vertragsgrundlage zwischen Client und Server. Typen werden nicht generiert, sondern direkt inferiert – ein Mechanismus, der bei vollständig TypeScript-basierten Stacks den Build-Prozess vereinfacht und Synchronisierungsfehler zwischen API-Definitionen und Client-Code strukturell ausschließt.
Typen werden nicht generiert, sondern direkt inferiert – ein struktureller Unterschied, der Synchronisierungsfehler zwischen API und Client von Grund auf verhindert.
Architektur in Produktionsumgebungen
Für den Einsatz in Produktionsumgebungen sind mehrere Aspekte relevant:
- Kommunikationsschicht: tRPC unterstützt sowohl HTTP- als auch WebSocket-basierte Kommunikation
- Framework-Integration: Express, Fastify und Next.js werden nativ unterstützt
- Routing-Muster: Prozeduren werden als
query,mutationodersubscriptiondefiniert und auf dem Server exponiert
Ein wichtiges Merkmal für skalierbare Architekturen ist die Middleware-Unterstützung. Authentifizierung, Logging und Fehlerbehandlung lassen sich als wiederverwendbare Schichten implementieren, die über mehrere Prozeduren hinweg greifen. In Kombination mit Zod für Input-Validierung entsteht ein durchgehend typsicheres System – vom Datenbankmodell bis zum Frontend-Hook.
Komposition vs. Federation
Die Komposition mehrerer tRPC-Router – vergleichbar mit dem Konzept der Subgraphen in Apollo Federation – ist über das Merging von Routern möglich. Dabei handelt es sich jedoch um eine statische Komposition zur Build-Zeit, nicht um eine dynamische Laufzeitkomposition wie bei Federation.
Für Microservice-Architekturen, in denen Teams unabhängig deployen und Schemas zur Laufzeit zusammengeführt werden sollen, bleibt Apollo Federation strukturell leistungsfähiger.
Grenzen und Abwägungen
tRPC ist kein vollständiger Ersatz für GraphQL in allen Szenarien. Folgende Punkte sind bei der Technologieentscheidung zu berücksichtigen:
- Externe APIs für Drittparteien profitieren weiterhin von GraphQLs selbstdokumentierendem Charakter und der breiten Tooling-Landschaft
- Homogenität vorausgesetzt: tRPC setzt eine durchgängige TypeScript-Umgebung voraus – in gemischten Tech-Stacks wird das zur Einschränkung
- Schlankeres Ökosystem: Caching-Strategien, Persisted Queries und Federation-spezifische Optimierungen müssen manuell oder über externe Libraries abgebildet werden
Teams, die bereits in Apollo Federation investiert haben, werden den Wechsel selten aus rein technischen Gründen vollziehen.
Einordnung für deutsche Unternehmen
Für deutsche Softwareunternehmen und Entwicklungsteams, die neue interne Dienste oder Fullstack-Applikationen auf Basis von Next.js oder ähnlichen TypeScript-First-Frameworks aufbauen, bietet tRPC eine pragmatische Option. Der reduzierte Konfigurationsaufwand und die enge IDE-Integration können die Entwicklungsgeschwindigkeit messbar erhöhen.
In bestehenden GraphQL-basierten Infrastrukturen oder bei API-Produkten mit externen Konsumenten bleibt Apollo Federation die solidere Wahl. Die Entscheidung hängt letztlich weniger von der Technologie selbst ab als vom Reifegrad des Stacks und den Anforderungen an Interoperabilität.