Next.js 14: Server Actions in der Praxis

Vor einem Jahr habe ich über den App Router geschrieben und vieles als spannend, aber unfertig bezeichnet. Mit Next.js 14 ist ein Stück davon erwachsen geworden: Server Actions sind nun stabil. Ich habe sie in den letzten Wochen in echten Projekten eingesetzt, und sie verändern, wie ich über Datenmutationen denke.

Mutationen ohne Umweg

Bisher lief jede schreibende Operation über eine API-Route. Ein Formular schickte seine Daten an einen Endpunkt, dieser validierte, schrieb in die Datenbank und antwortete — und ich pflegte am Ende zwei getrennte Welten: das Frontend und die API dazwischen. Server Actions schließen diese Lücke. Ich schreibe eine Funktion, markiere sie mit "use server", und sie läuft garantiert auf dem Server.

async function speichern(formData) {
  "use server";
  const name = formData.get("name");
  await db.kontakt.create({ data: { name } });
  revalidatePath("/kontakte");
}

export default function Formular() {
  return (
    <form action={speichern}>
      <input name="name" />
      <button type="submit">Speichern</button>
    </form>
  );
}

Das action-Attribut des Formulars nimmt die Funktion direkt entgegen. Kein fetch, kein Endpunkt, kein manuelles Serialisieren. Und das Schöne: Es funktioniert auch ohne JavaScript im Browser, weil es auf dem Web-Standard der Formulare aufbaut. Progressive Enhancement, ohne dass ich extra dafür arbeite.

Die beste Abstraktion ist die, die eine ganze Schicht überflüssig macht — nicht die, die noch eine hinzufügt.

Was sich in der Praxis bewährt

In echten Projekten schätze ich vor allem revalidatePath und revalidateTag. Nach einer Mutation sage ich Next.js gezielt, welche Daten veraltet sind, und der Cache erneuert sich von selbst. Kein manuelles Nachladen, kein verwaister Zustand im Client.

Ehrlich gesagt brauchte es etwas Disziplin, die Grenze sauber zu ziehen. Server Actions sind kein Allheilmittel — für komplexe, mehrstufige Flows oder öffentliche Schnittstellen greife ich weiter zu echten Endpunkten. Und Validierung gehört zwingend auf den Server, denn der Client lügt grundsätzlich.

Aber für das, was ich am häufigsten baue — Formulare, kleine Mutationen, der ganz normale Alltag einer Anwendung —, fühlen sich Server Actions richtig an. Sie entfernen eine Schicht, die ich nie geliebt habe. Das ist die Art von Fortschritt, die ich mag: weniger Code, der mehr sagt.