Server Components verändern nicht die Syntax, sondern die Frage, die man sich beim Schreiben einer Komponente stellt. Bisher lautete sie: Woher bekomme ich die Daten. Jetzt lautet sie: Muss dieser Teil überhaupt im Browser laufen.
Die meisten Schwierigkeiten in der Praxis entstehen daraus, dass diese Frage nicht bewusst gestellt wird.
Der häufigste Denkfehler
Sobald eine Komponente einen Zustand oder ein Ereignis braucht, wird sie zur Client-Komponente erklärt. Das ist richtig — aber alles, was innerhalb dieser Komponente eingebunden wird, wandert mit in den Browser.
Eine Seite, die ganz oben zur Client-Komponente wird, weil dort ein aufklappbares Menü sitzt, ist damit vollständig eine Client-Anwendung. Der Vorteil der serverseitigen Ausführung ist in diesem Moment verloren, ohne dass es jemand bemerkt.
Die Gegenmassnahme ist ein Zuschnitt, der die Grenze so tief wie möglich zieht: nicht die Seite interaktiv machen, sondern die interaktive Komponente. Was serverseitig bleiben kann, wird als Kindelement hineingereicht statt darin eingebunden.
Datenbeschaffung nahe an der Verwendung
Der ungewohnte Teil ist, dass Daten dort geholt werden dürfen, wo sie gebraucht werden — nicht zwingend an der Wurzel und dann durchgereicht. Das entzerrt Komponenten erheblich.
Die Sorge vor mehrfachen identischen Abfragen ist berechtigt und wird durch Zusammenfassung innerhalb einer Anfrage adressiert: Gleiche Abfragen innerhalb desselben Durchlaufs werden zu einer. Damit ist die Beschaffung nahe an der Verwendung kein Nachteil mehr.
Wo diese Zusammenfassung nicht greift, weil Aufrufe nicht identisch sind, entsteht das bekannte Muster von Abfragen in Schleifen — nur an einer neuen Stelle. Mitzuprotokollieren, wie viele Abfragen eine Seite auslöst, bleibt deshalb sinnvoll.
Wasserfälle statt Parallelität
Wenn eine Komponente auf Daten wartet und erst danach eine zweite Beschaffung startet, entsteht eine Kette. Bei drei Ebenen summieren sich die Wartezeiten.
Der Ausweg ist, unabhängige Beschaffungen gemeinsam zu starten statt nacheinander, und Bereiche, die unterschiedlich schnell fertig werden, mit einer Ladegrenze zu versehen. Der Rest der Seite erscheint dann sofort.
Für Dashboards ist das der wichtigste Hebel überhaupt: Ein einzelnes langsames Widget darf nicht die ganze Seite aufhalten.
Server Actions sind öffentliche Endpunkte
Eine Server Action sieht aus wie eine Funktion und ist ein Endpunkt, den jeder aufrufen kann, mit Argumenten seiner Wahl. Die Prüfung, ob die aufrufende Person berechtigt ist, gehört deshalb in die Action selbst.
Die Prüfung in der Komponente, die den Knopf rendert, ist wirkungslos — sie steuert nur, ob der Knopf sichtbar ist. Der Endpunkt existiert unabhängig davon.
Ebenso gehört die Validierung der Eingaben in die Action, serverseitig, gegen ein Schema. Was im Formular geprüft wurde, sagt nichts über das aus, was tatsächlich ankommt.
Zwischenspeicherung ist der Teil, der überrascht
Das Zusammenspiel aus statischer Erzeugung, Zwischenspeicherung der Datenbeschaffung und Neuvalidierung ist die häufigste Quelle für Verhalten, das in der Entwicklung anders aussieht als im Betrieb.
Für mandantenfähige Anwendungen ist die Regel wichtig: Alles, was mandantenabhängige Daten enthält, wird nicht ohne Mandantenkontext zwischengespeichert. Ein zwischengespeichertes Ergebnis, das an den falschen Mandanten geht, ist ein Vorfall, kein Fehler.
Bewährt hat sich, für alles Personalisierte die Zwischenspeicherung ausdrücklich abzuschalten und nur dort einzuschalten, wo bewusst entschieden wurde — nicht umgekehrt.
Wo Client-Komponenten weiterhin richtig sind
Formulare mit unmittelbarer Rückmeldung, Zeichenflächen, Editoren, Drag-und-Drop, alles was auf schnelle Interaktion angewiesen ist. Diese Teile serverseitig zu erzwingen, verschlechtert das Ergebnis.
Die Kunst liegt nicht darin, alles auf den Server zu holen, sondern darin, die Grenze bewusst zu ziehen — und sie so zu ziehen, dass sie nicht mehr mitnimmt als nötig.