Serveraktionen in Next.js: Mutationen ohne alleinige Pflege einer API

Es gibt eine Art Code, den jedes Team schreibt, ohne es zu hinterfragen: die Klebeschicht zwischen dem Formular und der Datenbank. Ein Endpunkt, der den POST empfängt, den Text validiert, den Dienst aufruft und einen JSON zurückgibt. Auf der anderen Seite ein fetch auf dem Client, der diesen Körper zusammenstellt, den Fehler behandelt und den Status aktualisiert. Multiplizieren Sie das mit jeder Produktschreibaktion und Sie haben Hunderte von Zeilen, die nur dazu dienen, Daten von einer Seite auf die andere zu verschieben.

Serveraktionen in Next.js greifen genau diesen Kleber an. Der Vorschlag ist unkompliziert: Führen Sie Mutationen (Schreiben, Aktualisieren, Löschen) über eine Funktion aus, die auf dem Server ausgeführt wird und direkt von der Komponente aufgerufen wird, ohne dass Sie dafür eine dedizierte REST-API entwerfen, versionieren und verwalten müssen. Der Endpunkt existiert noch, aber das Framework generiert und verbindet ihn für Sie.

Was sich in der Praxis ändert

Eine Serveraktion ist eine asynchrone Funktion, die für die Ausführung auf dem Server vorgesehen ist. Sie verknüpfen es mit einem Formular oder einem Ereignis, und Next.js kümmert sich um den Transport: serialisiert die Argumente, führt den Netzwerkaufruf durch und gibt das Ergebnis zurück. Aus der Sicht desjenigen, der den Bildschirm schreibt, sieht es so aus, als würden Sie lediglich eine lokale Funktion aufrufen.

Der Unterschied zum Vorgängermodell besteht in weniger Code und weniger Synchronisationspunkten. Es gibt keinen API-Vertrag mehr, um die Abstimmung zwischen zwei Seiten sicherzustellen, und auch kein Anforderungsschema, das mit dem übereinstimmen muss, was der Client sendet. Die Funktion, die die Anfrage aufzeichnet, und der Bildschirm, der diese Aufzeichnung auslöst, liegen dicht beieinander, und der Rückgabetyp ist an beiden Enden gleich.

Dies ist wichtig, da die meisten Spannungen in Produktteams nicht in der Geschäftslogik, sondern im Klebstoff liegen. Jede Mutation, die zuvor eine Routendatei, einen Handler, einen Abruf-Client und einen gemeinsam genutzten Typ erforderte, passt jetzt in eine Funktion. Weniger Angriffsfläche für Fehler, weniger Dateien zum Öffnen, wenn etwas kaputt geht.

Der Produktivitätsgewinn ist real, aber nicht der zentrale Punkt

Es ist verlockend, Serveraktionen als Abkürzung für Produktivität zu verkaufen, und das ist auch der Fall. Aber wenn man den Diskurs auf „weniger Standard“ reduziert, wird unterschätzt, was passiert. Der wichtigste Vorteil ist architektonischer Natur: Sensible Logik durchläuft nicht mehr den Client.

Wenn die Mutation auf dem Server läuft, müssen der API-Schlüssel, die Bankzugangsdaten, die Preisregel, die Provisionsberechnung, nichts davon an den Browser gesendet werden. Der Client löst die Absicht („diese Anfrage erstellen“) aus und der Server entscheidet, was das bedeutet. Der Code, auf den es ankommt, verlässt niemals die von Ihnen kontrollierte Umgebung.

Dadurch wird eine ganze Klasse von Lecks behoben, die das traditionelle SPA-Modell verbreitet hat. Die Teams verteilten die Geschäftslogik im Frontend, weil es dort am praktischsten war, und stellten dann fest, dass Rabattregeln oder Limitvalidierungen im Paket offengelegt wurden. Mit der standardmäßigen Mutation auf dem Server verschwindet die Versuchung: Diese Logik kann nirgendwo auf dem Client abgelegt werden, da der Client nur den Aufruf kennt.

Um zu verstehen, warum der Server zum natürlichen Ort für diese Logik geworden ist, lohnt es sich, die umfassendere Idee der Server-First-Architektur im Web4 noch einmal zu betrachten, zu der auch Serveraktionen gehören.

Die Warnung, die niemand überspringen kann: Einreise als feindselig behandeln

Hier ist der Teil, der diejenigen unterscheidet, die Serveraktionen gut nutzen, von denen, die eine hübsche Sicherheitslücke schaffen. Eine Serveraktion ist ein öffentlicher Endpunkt. Die Tatsache, dass Sie es nur aus einer hübschen Form in Ihrer eigenen Anwendung aufrufen, ändert daran nichts.

Wenn Next.js die Aktion generiert, stellt es eine Route bereit, die Aufrufe akzeptiert. Jeder, der über das richtige Werkzeug verfügt, kann eine Anfrage dafür fälschen, mit beliebigen Argumenten und in beliebiger Reihenfolge. Die von Ihnen entworfene Schnittstelle stellt kein Hindernis dar: Sie ist nur eine der Möglichkeiten, diese Funktion aufzurufen. Zu denken „Aber meine Front würde diesen Wert nie senden“ ist der klassische Fehler, weil der Angreifer seine Front nicht nutzt.

Daraus ergeben sich zwei nicht verhandelbare Verpflichtungen. Die erste ist die Validierung. Jedes eingehende Argument muss auf dem Server mit einem expliziten Schema überprüft werden, bevor eine Geschäftsregel berührt wird. Typ, Format, Wertebereich, Vorhandensein von Feldern. Die Eingabe von TypeScript hilft während der Entwicklung, verschwindet aber zur Laufzeit; Es validiert nichts von denen, die die Route von außen aufrufen.

Die zweite ist die Autorisierung und unterscheidet sich von der Validierung. Validate antwortet: „Sind diese Daten sinnvoll?“ Authorize antwortet: „Kann diese Person das tun?“ Jede Serveraktion, die ihren Status ändert, muss in sich selbst überprüfen, wer der Benutzer ist und ob er oder sie die Berechtigung für diesen Vorgang auf dieser Ressource hat. Verlassen Sie sich nicht darauf, die Schaltfläche in der Benutzeroberfläche ausgeblendet zu haben. Die versteckte Schaltfläche schützt die Funktion nicht; Nur wenn man nach innen schaut, schützt es.

Warum müssen diese Kontrollen in die Aktion integriert werden?

Es besteht die Versuchung, die Autorisierung in der Middleware zu zentralisieren und die Angelegenheit als gelöst zu betrachten. Middleware hilft, aber sie arbeitet oft auf Routenebene und nicht auf Ressourcenebene. Es kann heißen: „Dieser Benutzer ist angemeldet“ und seltener: „Dieser Benutzer besitzt genau die Bestellung, die er stornieren möchte“.

In diesem Unterschied leben die teuersten Ausfälle. Ein authentifizierter und legitimer Benutzer kann versuchen, auf eine Ressource zu reagieren, die ihm nicht gehört, indem er einfach einen Bezeichner im Aufrufargument ändert. Authentifizierung bestanden; Die Autorisierung für das spezifische Objekt ist fehlgeschlagen. Aus diesem Grund gehört die Berechtigungsprüfung zum Hauptteil der Aktion, in der Nähe der Geschäftsregel, wo Sie den vollständigen Kontext dessen haben, was geändert wird und für wen.

Das Prinzip ist alt und es lohnt sich, ausführlicher über Grundlagen der Sicherheit in Webanwendungen zu lesen: Jede Grenze zwischen dem, was der Benutzer fragt, und dem, was das System tut, ist ein Kontrollpunkt. Serveraktionen schaffen diese Grenze nicht, sie machen sie diskreter, und das Diskrete ist genau das, was zu schützen vergisst.

Wie man über eine Adoption nachdenkt, ohne dass es zu einem Chaos kommt

Serveraktionen machen eine Serviceschicht nicht überflüssig. Wenn Sie die gesamte Geschäftslogik in die Aktionen integrieren, wird das Fat-Controller-Problem neu erstellt, nur mit einem anderen Namen. Die Aktion muss dünn sein: Sie empfängt den Aufruf, validiert ihn, autorisiert ihn und delegiert ihn an eine Domänenfunktion, die nichts über HTTP oder Next.js weiß.

Durch diese Trennung bleibt die Logik testbar und wiederverwendbar. Dieselbe Regel zum Erstellen einer Reihenfolge kann von einer Aktion, einem Warteschlangenauftrag und einem Importskript aufgerufen werden, sofern sie außerhalb der Aktion vorhanden ist. Behandeln Sie die Serveraktion wie eine Eingangstür, nicht den gesamten Raum.

Es lohnt sich auch, ehrlich darüber zu sein, wann eine traditionelle API noch Sinn macht. Wenn Sie externe Kunden, eine native mobile App oder Integrationen von Drittanbietern haben, ist eine versionierte und dokumentierte API immer noch die richtige Antwort. Serveraktionen glänzen durch die Verbindung zwischen Ihrer Vorder- und Rückseite; Sie waren nicht als öffentlicher Vertrag konzipiert, den ein Partner in Anspruch nehmen würde. Wie dies in den Rest des Frameworks passt, wird im Next.js App Router-Leitfaden“ deutlicher.

Was ist bei der Entscheidung zu berücksichtigen?

Serveraktionen reduzieren die Code-Unordnung und übertragen sensible Logik standardmäßig auf den Server, was gleichzeitig eine Produktivitäts- und Sicherheitsverbesserung darstellt. Das ist das Argument, das dafür spricht, und es ist für die meisten Anwendungen stark, bei denen letztendlich die Vorderseite mit der Rückseite spricht.

Der Preis ist Disziplin. Jede Aktion ist ein öffentlicher Port und muss als solcher behandelt werden: explizite Validierung, Autorisierung auf Ressourcenebene, Domänenlogik außerhalb davon. Diejenigen, die dies als ein Detail betrachten, tauschen sichtbare Muster gegen unsichtbare Risiken ein, und unsichtbare Risiken sind die Art, die im schlimmsten Moment in der Produktion auftauchen.

Wenn Sie die Architektur einer neuen Next.js]-Anwendung entwerfen, lohnt es sich, von Anfang an zu modellieren, wo die Vertrauensgrenzen liegen, bevor Sie Aktionen im gesamten Code verteilen. Wenn Sie sich über diese Zeichnung austauschen möchten, rufen Sie mich in den Kommentaren oder in den Netzwerken an.