Die Zukunft umarmen und wieder zurückkehren: Von Serveraktionen zu tRPC

Am 26. Oktober 2022, während der Next.js Conf, stellte Vercel Next.js 13 vor und brachte eine Menge neuer Funktionen sowie einen völlig neuen Paradigmenwechsel für die Erstellung von Next.js-Anwendungen mit sich.

React Server Components (RSCs) sind seit einiger Zeit bekannt, wurden jedoch noch nicht in einem React-Meta-Framework implementiert. Da Next.js sie nun hinzufügt, sollte sich die Welt der serverseitig gerenderten React-Anwendungen ändern.

Das Versprechen von React Server Components

Von Vercel als ein Werkzeug beschrieben, um UIs, die auf dem Server gerendert oder optional zwischengespeichert werden, zu schreiben, versprach RSC eine direkte Integration mit Datenbanken und server-spezifischen Funktionen – ein Abweichen von den typischen React- und SSR-Modellen.

Dieses Feature erschien zunächst als Wendepunkt und versprach einfacheres Datenabrufen und Routing, dank asynchroner Serverkomponenten und zusätzlicher Unterstützung für verschachtelte Layouts.

Nach etwa sechs Monaten Experimentieren mit anderen Projekten kam ich zu dem Schluss, dass es zwar ein wenig rauh um die Kanten war, es in der Tat ein Wendepunkt war und etwas, das in zukünftige Next.js-Projekte übernommen werden sollte.

Ein neues Paradigma: Server Actions

Vercel hörte nicht auf, Server Components hinzuzufügen. Kurz nach der ersten Next.js 13-Version führten sie "Server Actions" ein. Server Actions ermöglichen das Aufrufen von serverseitigen Funktionen ohne API-Routen und reduzieren die nötige Zeremonie, um eine neue Mutation oder ein Ereignis zu Ihrer Anwendung hinzuzufügen.

Auf neue Technologie setzen

Nach der Veröffentlichung von Server Actions und Server Components begaben wir uns bei Documenso an eine Neuschreibung der Anwendung. Wir hatten ein wenig technische Schulden aus dem ursprünglichen MVP angesammelt, die am besten abgebaut wurden, während wir das Design auch mit Hilfe unseres neuen Designers verbesserten.

Nachdem ich mit Server Components in anderen Projekten viel Erfolg hatte, entschied ich mich, sowohl auf Server Components als auch auf Server Actions für die neue Version der Anwendung zu setzen. Ich war gespannt, wie viel einfacher und effizienter die Anwendung mit diesen neuen Technologien sein würde.

Nach unserem Relaunch waren wir mit unseren Entscheidungen in Bezug auf Server Actions sehr zufrieden, die es uns ermöglichten, bestimmte Client- und serverseitige Logik in einer einzigen Komponente zu kombinieren, ohne dass wir viel Aufwand betrieben mussten.

Herausforderungen mit Server Actions bewältigen

Obwohl wir anfangs erfolgreich waren, stießen wir bald auf Probleme mit Server Actions, insbesondere beim Monitoring der Anwendung. Leider macht es der Einsatz von Server Actions viel schwieriger, Netzwerk-Anfragen zu überwachen und fehlgeschlagene Server Actions zu identifizieren, da sie die Route verwenden, auf der sie sich gerade befinden.

Trotz dieses Problems waren die Dinge handhabbar; jedoch trat ein kritisches Problem auf, als die Verwendung von Server Actions zu einer Bündelbeschädigung führte, was zu einer top-level await-Einfügung führte, die die Builds und Tests zum Scheitern brachte.

Dieses letzte Problem war ein Dealbreaker, da es zeigte, wie viel Magie wir mit Server Actions relied on. Ich versuche, wo immer möglich, mehr Magie zu vermeiden, da wir mit Bundlern und Meta-Frameworks bereits einiges an schwerer Arbeit abgeben und viel Magie im Gegenzug erhalten.

Voll und ganz auf tRPC setzen

Meine schnelle und endgültige Lösung für die Probleme, mit denen wir konfrontiert waren, bestand darin, tRPC voll und ganz zu nutzen, das wir bereits in anderen Bereichen der Anwendung verwendet haben. Die Migration dauerte weniger als einen Tag und löste alle unsere Probleme, während sie auch viel mehr Sichtbarkeit für fehlgeschlagene Aktionen hinzufügte, da sie jetzt eine dedizierte API-Route hatten.

Für diejenigen, die mit tRPC nicht vertraut sind: Es ist ein Framework zum Erstellen von End-to-End-typsicheren APIs mit TypeScript und Next.js. Es ist eine großartige Bibliothek, die es Ihnen ermöglicht, Ihre definierten APIs sicher innerhalb des Clients aufzurufen, wodurch zur Build-Zeit Fehler auftreten, wenn Dinge unvermeidlich abweichen.

Ich bin seit einiger Zeit ein großer Fan von tRPC, sodass die Entscheidung, Server Actions fallen zu lassen und stattdessen mehr tRPC zu verwenden, mir leicht fiel.

Gelerntes und die Zukunft

Während ich glaube, dass Server Actions eine großartige Idee sind und ich sicher bin, dass sie in Zukunft verbessert werden, habe ich die Lektion erneut gelernt, dass es am besten ist, Magie wo immer möglich zu vermeiden.

Das bedeutet nicht, dass wir in Zukunft nicht in Betracht ziehen werden, bestimmte Dinge zurück zu Server Actions zu bewegen. Aber vorerst werden wir abwarten und beobachten, wie andere sie nutzen und wie sie sich entwickeln.