tRPC vs GraphQL — Warum tRPC endlich das Problem mit der Typsicherheit behebt

Die Typsicherheit mit GraphQL war ein Problem, daher war TrPC längst überfällig

tRPC ist kürzlich in der TypeScript-Community berühmt geworden, und ich wage zu sagen, dass eine Bibliothek wie diese längst überfällig war. In der Vergangenheit war das Erreichen der Typsicherheit eine mühsame Aufgabe. Die üblichen Optionen waren entweder das manuelle Erstellen und Verwalten von Typen oder die Verwendung von GraphQL mit einem Codegenerator.

Interessanterweise haben viele Entwickler eine der wichtigsten Funktionen von GraphQL vernachlässigt — den Sprachagnostizismus. Darüber hinaus haben einige von uns die Dinge kompliziert, indem sie ein Schema aus unserem TypeScript-Code generierten (oder es sogar selbst geschrieben haben) und dann alles für unsere Webanwendung wieder in TypeScript umwandelten.

Um es einfacher zu machen sorgen Sie für Typsicherheit und müssen sich nie mit der komplexen Konfiguration auseinandersetzen Wieder von TypeScript und GraphQL, habe ich beschlossen, TrPC auszuprobieren. Schauen wir uns an, wie sie unter der Haube funktionieren und vergleichen wir sie miteinander.

tRPC-Anfragen basieren auf Prozeduren, während Graph Query Language selektive Daten anfordert

tRPC ist ein Tool speziell für TypeScript und Monorepos entwickelt. In einfachen Worten, es integriert die Typen aus dem Backend in den Webclient. Sie können optional die Rückgabetypen angeben, aber tRPC kann sie automatisch ableiten. Das bedeutet, dass Sie nichts generieren oder neu laden müssen. Wenn sich die Eingabe ändert, wird sofort ein Fehler in Ihrem Frontend-Code angezeigt. Der Frontend-Client basiert auf TANStack-Abfrage mit einigen Anpassungen, sodass Sie keine neue Syntax lernen müssen, um die API zu integrieren.

Andererseits ermöglicht uns GraphQL, nur die erforderlichen Felder anzufordern, was insbesondere für mobile Apps ein bahnbrechendes Feature ist. Ich bin jedoch bereit, dies für die Geschwindigkeit und Effizienz zu opfern, die tRPC bietet. Lassen Sie uns dies anhand eines einfachen schrittweisen Vergleichs beider Ansätze demonstrieren.

Wie tRPC und GraphQL funktionieren — Demoprojekt

In beiden Fällen werde ich eine einfache Suche implementieren.

Ich werde Prisma verwenden, um meine PostgreSQL-Datenbank zu modellieren. In der Datei schema.prisma definiere ich ein einfaches Modell:

GraphQL einrichten

Den Endpunkt erstellen

Für den GraphQL-Teil werde ich NestJS verwenden, da es einen Code-First-Ansatz zum Generieren von GQL-Schemas ermöglicht.

Um das Schema zu generieren, muss ich eine Verbindung zwischen TypeScript und GraphQL erstellen. Dazu muss ich eine Klasse für meinen Rückgabetyp definieren, die mit @ObjectType dekoriert ist.

GraphQL versteht TypeScript-Enumerationen nicht von Haus aus, daher musste ich auch meine Enumeration registrieren.

Als Nächstes erstellen Sie einen Resolver und eine darin enthaltene Abfrage, die die Frucht zurückgibt. Resolver liefern die Anweisungen, die erforderlich sind, um GraphQL-Operationen (in diesem Fall eine Abfrage) in Daten umzuwandeln.

Um eine GraphQL-Schemaabfrage zu generieren, habe ich den @Query () Decorator verwendet, für den ich den zuvor erstellten Rückgabetyp und einen Abfragenamen angegeben habe.

Die Übergabe von Argumenten an eine Abfrage kann über den @Args Decorator erreicht werden. Wie zuvor muss ich auch den GraphQL-Typ angeben, nicht nur den TypeScript-Typ.

Nach diesen Schritten kann ich sehen, dass meine Schemadatei meine API in GraphQL widerspiegelt. Der Typ, den ich erstellt habe, ist vorhanden, ebenso wie die Enumeration und die Abfrage.

Eine Datums-/Uhrzeit-Zeichenfolge bei UTC, z. B. 2019-12-03T 09:54:33 Z, die dem Datums-/Uhrzeitformat entspricht.

Frontend-Teil

Ich beginne mit der Integration meiner GraphQL-API, indem ich Codegen.

Dann muss ich eine Abfrage schreiben, um die Daten zu definieren, die ich abrufen möchte.

Nach dem Ausführen des Codegenerators sind meine Typen bereit und ich kann sie verwenden, um die useQuery von ApolloClient einzugeben.

Wie Sie sehen, muss ich den Typ selbst angeben, useQuery kennt die Typen nicht, nur weil ich das Dokument bereitgestellt habe.

tRPC-Einrichtung

Den Endpunkt erstellen

Zuerst muss ich eine Prozedur erstellen — eine Logik, die ausgeführt wird, wenn eine Route erreicht wird.

Dieses Mal muss ich den Rückgabetyp nicht angeben, aber ich muss eine Eingabe erstellen. Ich habe gewählt Zod als mein Validator, aber tRPC unterstützt mehrere Validierungsbibliotheken sowie benutzerdefinierte Validierungen.

Die Prozedur wird die Eingabe und das Prisma als Parameter haben. PrismaClient wird durch den TrPC-Kontext geleitet.

Jetzt ist die Logik bereit, an eine Route angehängt zu werden. Um das zu erreichen, werde ich einen Router für alle meine Operationen im Zusammenhang mit Obst erstellen.

Router können mit CreateTRPCRouter von jedem Punkt Ihrer Anwendung aus erstellt werden. Sie müssen jedoch mit dem Haupt-ApRouter verbunden sein.

Standardmäßig stehen Ihnen PublicProcedures zur Verfügung, Sie können jedoch auch eingeschränkte Procedures verwenden, indem Sie Middlewares erstellen. Prozeduren verwenden das Builder-Muster, was sie sehr flexibel macht. Ich werde Eingabe- und Abfragekonstruktionsschritte verwenden. Um Daten zu ändern, sollte man Mutation verwenden, genau wie in GraphQL.

Frontend-Teil

TrPC kann mit etwas grundlegendem Boilerplate-Code einfach in Next.js integriert werden. Hier sind einige Beispiele für Bootstrapper, die ich persönlich sehr mag T3-Stapel.

Der Boilerplate-Code transformiert eine Next.js API-Route so, dass sie als API-Handler funktioniert. tRPC selbst ist kein Backend-Framework, es wird an einen Adapter Ihrer Wahl angehängt. Die vollständige Liste der unterstützten Adapter finden Sie hier.

Die Client-Konfiguration ist auch im Boilerplate-Code enthalten.

Wann immer ich meine Abfrage verwenden möchte, rufe ich einfach die richtige TANStack-Query-Methode für eine Prozedur von meinem Router aus auf. Alles ist sofort einsatzbereit, sodass nur noch sehr wenig Platz für Fehler bleibt. Ich weiß bereits, welche Art von Prozeduren ich von jedem meiner Router aus aufrufen kann und welche Methoden von TANStack Query für eine bestimmte Prozedur verfügbar sind.

tRPC ist das Tool der Wahl, wenn Änderungen unerlässlich sind

Wenn ich Früchte auch nach ihrem Typ suchen würde, müsste ich das neue Argument in die GraphQL-Abfrage in meiner Web-App aufnehmen. Der Compiler benachrichtigt mich nicht automatisch über ein neues obligatorisches Argument. Wenn ich vergessen würde, die Abfrage zu korrigieren, würde ich eine Fehlermeldung vom Server erhalten. Wenn ich die Abfrage ändere, muss ich auch Codegen erneut ausführen.

Änderungen wie diese sind mit tRPC viel einfacher.. Nachdem ich mein Zod-Eingabeobjekt geändert habe, fordert mich der Compiler sofort auf, meine Eingabe auf der Clientseite zu korrigieren.

TrPC vs GraphQL: Mit tRPC können Sie im Vergleich zu GraphQL mit weniger Aufwand mehr erreichen

Wenn Sie nicht vorhaben, sprachunabhängig zu sein, und es keine Umstände gibt, unter denen die Möglichkeit, nur nach den erforderlichen Feldern zu fragen, entscheidend für die Optimierung von Abfragen und die Verbesserung der Leistung Ihrer App ist, ist GraphQL möglicherweise eine Wahl, die den Entwicklungsprozess nur um eine Reihe von Aufgaben erweitert.

EIN Eine gut gestaltete tRPC-API führt zu einer vollständig typsicheren App das kann sein mühelos modifiziert. Jeder Punkt Ihrer App wird die verfügbaren Routen, ihre Typen (Mutation/Abfrage) und Eingaben kennen.

Der einzige Nachteil von tRPC, den ich bisher beobachten konnte, ist das Fehlen einer Konvention, die zu schwer zu wartendem Code führen kann.

Die Autoren von tRPC selbst sind große Fans von GraphQL, und ich könnte ihnen nicht mehr zustimmen:

<blockquote><p>Wenn Sie bereits einen benutzerdefinierten GraphQL-Server für Ihr Projekt haben, möchten Sie tRPC möglicherweise nicht verwenden. GraphQL ist unglaublich; es ist großartig, eine flexible API erstellen zu können, bei der jeder Verbraucher genau die Daten auswählen kann</p>, die er benötigt. <p>Die Sache ist, GraphQL ist nicht so einfach richtig zu machen — ACL muss pro Typ gelöst werden, und Komplexitätsanalyse und Leistung sind alles andere als triviale Dinge</p>. <p>tRPC ist viel einfacher und verbindet Ihren Server und Ihre Webseite/App enger miteinander (zum Guten und zum Schlechten). Es ermöglicht Ihnen, schnell zu handeln, Änderungen vorzunehmen, ohne ein Schema aktualisieren zu müssen, und vermeiden, über den ständig durchquerbaren Graphen nachzudenken</p></blockquote>.

Am Ende des Tages kommt es für mich als Entwickler darauf an, wie effektiv ein Tool ist und wie viel Aufwand ich benötige, um diese Effektivität zu erreichen. TrPC senkt den Aufwand und verbessert gleichzeitig die Wirkung im Vergleich zu GraphQL.