Ein Entwickler verbrachte zwei Wochen damit, eine REST-API in einem internen Tool durch tRPC zu ersetzen.

Warum der Wechsel wichtig war

Der alte Stack zwang uns dazu, ein DTO, einen Validator und einen separaten Satz TypeScript-Typen für das Frontend zu pflegen. Benannte man ein Backend-Feld um, lieferte die API weiterhin einen 200er-Status, das UI renderte weiter, und der Fehler trat lediglich als „undefined“-Werte auf. Ein Kunde bemerkte das Problem, noch bevor es jemand im Team tat. REST-Contracts verbargen das Problem, und die zusätzlichen Dateien verursachten einen Wartungsaufwand, der sich nie auszahlte.

So sah das REST-Setup aus

  • OpenAPI-Spec – eine statische Datei, die Endpunkte beschrieb, aber nie als Source of Truth diente.
  • Client-SDK-Generierungsschritt – ein CI-Job, der einen JavaScript-Wrapper erzeugte.
  • Postman-Collection – ein gemeinsam genutztes Test-Artefakt, das niemand verwendete.
  • Manuelle TypeScript-Interfaces – handgeschriebene Typen, die mit dem Server synchron gehalten werden mussten.

Jede API-Änderung betraf mindestens drei dieser Artefakte, plus den Validator und alle nachgelagerten Fetch-Aufrufe. Der Prozess war fehleranfällig und langsam.

Wie tRPC die Codebasis schlanker machte

tRPC macht die separate Contract-Datei überflüssig. Der Server exportiert einen Router-Typ; der Client importiert denselben Typ. Benennt man ein Backend-Feld um, markiert der Editor den Fehler sofort – ohne Code auszuführen oder einen fehlgeschlagenen Request abzuwarten. Der Entwickler entfernte:

  • Die OpenAPI-Spec-Datei.
  • Den Client-SDK-Generierungsschritt.
  • Die ungenutzte Postman-Collection.
  • Den Ordner mit den manuellen TypeScript-Interfaces.

Das Repo wurde schlanker, und das Feedback kam bereits während der Entwicklung statt erst nach dem Deployment.

Grenzen von tRPC

tRPC funktioniert nur, wenn beide Seiten TypeScript sprechen. Es stößt an Grenzen, wenn:

  • Ein Mobile-Team Swift oder Kotlin verwendet.
  • Die API von externen Partnern konsumiert werden muss.
  • Sie eine öffentliche, sprachunabhängige Schnittstelle benötigen.

Was die Migration tatsächlich erforderte

Der zweiwöchige Aufwand war mehr als nur Copy-and-Paste. Der Entwickler musste:

  • Jeden fetch-Aufruf umschreiben, um die Client-Funktionen von tRPC zu nutzen.
  • Die Error-Handling-Logik anpassen.
  • UI-Komponenten aktualisieren, die auf Loading- und Retry-States angewiesen waren, die an rohe HTTP-Responses gebunden waren.

Fragen, die man sich vorab stellen sollte

  • Nutzen sowohl Frontend als auch Backend TypeScript? Ohne ein gemeinsames Typsystem verliert tRPC seinen Hauptvorteil.
  • Ist dasselbe Team für beide Seiten verantwortlich? Lücken in der Zuständigkeit können wieder zu Contract Drift führen.
  • Beheben Sie einen konkreten Bug oder folgen Sie einem Trend? Der Produktivitätsschub ist real, aber er sollte ein bestehendes Problem lösen.

Ein hybrider Ansatz für 2025

Viele Teams finden den optimalen Mittelweg, indem sie beide Stacks parallel betreiben:

  • tRPC für interne Anwendungsschichten, in denen die Codebasis vollständig aus TypeScript besteht und dasselbe Team sowohl den Server als auch den Client verwaltet.
  • REST für Webhooks, öffentliche APIs und Partner-Integrationen, bei denen ein sprachunabhängiger Zugriff erforderlich ist.

Die Verwendung des richtigen Werkzeugs für jede Schnittstelle hält die interne Entwicklung schnell und bewahrt gleichzeitig die für externe Konsumenten notwendige Offenheit.

Fazit: Der Ersatz von REST durch tRPC kann doppelte Contract-Artefakte eliminieren und Fehler bereits während der Bearbeitung aufdecken. Die Vorteile stellen sich jedoch erst dann ein, wenn der gesamte Stack TypeScript nutzt und das Team die Migrationskosten tragen kann. Eine gemischte Strategie ermöglicht es, die Vorteile zu nutzen, ohne Konsumenten auszuschließen, die kein TypeScript verwenden.