Frontend- und Rendering-Architekturen

Frontend- und Rendering-Architekturen

0:00 Kaum ein Thema wird so stark über Frameworks diskutiert wie das Frontend — und kaum eines hat so direkte Folgen für Antwortzeiten, Auffindbarkeit und Betriebskosten. Deshalb drehen wir die übliche Reihenfolge um. Wir fragen nicht, welches Framework, sondern: Wo soll aus Daten eigentlich Darstellung werden? Auf dem Server, im Browser, einmalig beim Bauen?

0:20 Diese Entscheidung fällen Sie einmal pro Oberfläche, und sie entscheidet mehr über die Qualität Ihrer Anwendung als die Wahl der Bibliothek darüber.

Frontend- und Rendering-Architekturen

0:29 Fünf Kapitel liegen vor uns. Zuerst die Grundformen des Renderings und ihre Kosten. Dann die Komponentenmodelle, bei denen gerade die Grenze zwischen Frontend und Backend verschwimmt. Danach der Zuschnitt des Frontends im Großen — von der klassischen Seite bis zu Microfrontends. Dann die mobile Frage. Und am Ende eine Übung, in der Sie für zwei sehr verschiedene Oberflächen von Kartenwerk getrennt entscheiden.

Verteilung der Verantwortung zwischen Client und Server

0:54 Fangen wir mit der Kernfrage an. Rendering heißt: Aus Daten und Vorlagen wird Darstellung. Die Frage ist nur, an welchem Ort und zu welchem Zeitpunkt — und alles Weitere folgt daraus. Man kann sich das wie die Frage vorstellen, ob ein Gericht im Restaurant zubereitet, zu Hause gekocht oder auf Vorrat eingefroren wird. Serverseitig heißt: bei jeder Bestellung frisch. Clientseitig: Sie bekommen die Zutaten und kochen selbst. Statisch: einmal vorbereitet, für alle gleich, sofort verfügbar.

1:24 Jede Variante hat ihren Platz, und keine ist grundsätzlich besser. Was Sie brauchen, ist ein Blick für die Kosten — und die bezahlen bei den ersten beiden Varianten unterschiedliche Leute: einmal Ihr Server, einmal das Gerät Ihrer Nutzer. Achten Sie besonders auf die rechte Spalte, denn dort steht das, was in Framework-Vergleichen gern fehlt.

1:44 Serverseitiges Rendern ist schnell für den Nutzer und kostet Sie Rechenzeit bei jeder einzelnen Anfrage — bei einer Lastspitze ist das eine sehr reale Rechnung. Statisches Rendering ist unschlagbar günstig und scheitert, sobald Inhalte persönlich werden. Und die Maße in der Fußzeile sind entscheidend: Es gibt nicht „schnell", es gibt drei verschiedene Zeitpunkte, und die Varianten verschieben sie gegeneinander.

2:07 Eine Form kann beim ersten Wert gewinnen und beim dritten verlieren. Jetzt zu dem Effekt, der die meisten Nutzer wirklich ärgert, ohne dass sie ihn benennen könnten. Nach dem serverseitigen Rendern muss der Browser die fertige Seite noch mit Zustand und Interaktivität versehen — das nennt man Hydration. In dieser Phase sieht die Seite vollständig aus, reagiert aber auf nichts. Man tippt, und es passiert nichts.

2:31 Genau deshalb heißt dieser Zustand das unheimliche Tal: Die Seite verspricht etwas, das sie noch nicht halten kann. Auf schwachen Geräten dauert dieses Tal am längsten — also ausgerechnet dort, wo Geduld am knappsten ist. Drei technische Antworten und eine unbequeme. Streaming schickt die Seite in Teilen, statt auf ihre Vollendung zu warten. Progressive Hydration erweckt Bereiche nacheinander.

2:55 Islands Architecture geht noch weiter und belebt nur die Stellen, die wirklich interaktiv sind — der Rest bleibt gewöhnliches HTML. Und dann der vierte Punkt, der am wirksamsten ist und am seltensten gewählt wird: weniger Interaktivität. Für eine Veranstaltungsseite bei Kartenwerk braucht es keine Anwendung im Browser. Es braucht eine Seite, die schnell da ist, und einen Knopf, der funktioniert.

3:19 Der erste Punkt beschreibt den häufigsten Selbstbetrug im Frontend: Man rendert serverseitig, lädt aber trotzdem das gesamte Skriptbündel nach und hat damit die Kosten beider Welten. Der zweite ist verwandt — die Daten stehen doppelt in der Antwort, einmal gerendert und einmal als Zustand. Und der letzte Punkt ist der, den ich Ihnen wirklich ans Herz lege: Messen Sie auf einem alten Mobilgerät. Auf Ihrem Entwicklungsrechner ist jede Rendering-Strategie schnell.

3:45 Der Unterschied zwischen ihnen wird erst dort sichtbar, wo es darauf ankommt.

Moderne Komponentenmodelle

3:50 Damit zu einer Entwicklung, die gerade eine Grenze verschiebt, die zwanzig Jahre lang klar war: die zwischen Frontend und Backend. Server Components und Server Functions sind dabei mehr als ein technisches Detail. Der entscheidende Satz auf dieser Folie ist der über den Code. Eine Server Component rendert in einer eigenen Serverumgebung, und zum Browser geht nur ihr Ergebnis — nicht ihr Code.

4:12 Das klingt nach einer Feinheit und ist es nicht: Alle Bibliotheken, die diese Komponente braucht, bleiben auf dem Server. Wer schon einmal ein Bündel analysiert hat, weiß, wie viel davon aus Abhängigkeiten besteht, die nur an einer Stelle gebraucht werden. Client Components tragen weiterhin die Interaktivität, und Server Functions erlauben ihnen, kontrolliert serverseitige Funktionen aufzurufen.

4:35 Diese Gegenüberstellung räumt ein Missverständnis aus, das mir häufig begegnet. Beide Verfahren führen Komponentencode auf dem Server aus — soweit sind sie gleich. Der Unterschied steht in den mittleren Zeilen: Beim klassischen serverseitigen Rendern steckt derselbe Code zusätzlich im Bündel, weil der Browser ihn für die Hydration braucht.

4:55 Bei Server Components nicht. Und wichtig, weil es oft falsch verstanden wird: Das eine ersetzt das andere nicht. Server Components sitzen davor, beides existiert nebeneinander. Auf den ersten Blick liest sich das wie eine Mängelliste. Kein Zustand, keine Effekte, nur serialisierbare Werte über die Grenze. Tatsächlich sind diese Einschränkungen das Entwurfswerkzeug: Sie zwingen Sie, sich pro Komponente zu entscheiden, ob sie Interaktivität braucht oder nicht.

5:22 Diese Frage hat vorher kaum jemand gestellt, weil alles ohnehin im Browser lief. Die Serialisierbarkeit ist dabei die Grenze, die sich am deutlichsten bemerkbar macht — eine Funktion lässt sich nicht hinüberreichen. Wer damit arbeitet, sollte die Grenze im Code sichtbar halten, nicht verstecken. Jetzt wird es für unser Thema interessant.

5:43 Wenn der Datenzugriff in die Komponente rückt, verschiebt sich etwas Grundsätzliches: Der API-Vertrag, über den wir im nächsten Modul sprechen, wird an dieser Stelle umgangen. Das kann ein Gewinn sein — weniger Zwischenschichten, weniger Übersetzungsarbeit. Es kann auch bedeuten, dass Fachlogik unbemerkt ins Frontend wandert.

6:02 Ähnlich beim Caching: Es wird zur Frontend-Entscheidung. Für Kartenwerk heißt das, dass die Frage „öffentlich oder persönlich" plötzlich in der Komponente beantwortet wird. Der erste und der letzte Punkt sind die beiden gegensätzlichen Arten, es falsch zu machen. Entweder wird die Grenze so weit verschoben, bis wieder alles im Browser läuft — dann hat man nichts gewonnen.

6:24 Oder das Team versteht Server Components als Ersatz für das Backend und schiebt Fachlogik dorthin. Beides sind keine technischen Fehler, sondern Verständnisfragen. Und der dritte Punkt ist der tückische: Fehlerbehandlung endet gern an der Grenze. Was serverseitig schiefgeht, kommt im Browser als leere Stelle an — ohne Meldung, ohne Protokoll.

Frontend-Architekturen im Vergleich

6:45 Zoomen wir eine Ebene heraus. Nicht mehr die einzelne Komponente, sondern der Zuschnitt des gesamten Frontends: Wie viele Auslieferungseinheiten gibt es, und wer verantwortet sie? Beachten Sie, dass in dieser Definition zweimal das Wort „verantwortet" vorkommt. Das ist kein Zufall. Die Unterschiede zwischen diesen Zuschnitten sind nur oberflächlich technisch — im Kern geht es darum, wie viele Teams unabhängig voneinander etwas veröffentlichen können sollen.

7:12 Das ist dieselbe Logik, die uns in Modul acht bei Monolith und Microservices wieder begegnet. Frontend-Architektur ist Organisationsentwurf mit anderen Mitteln. Die rechte Spalte formuliert bewusst Bedingungen, keine Empfehlungen. Die erste Zeile wird dabei am meisten unterschätzt: Wenn Inhalte im Vordergrund stehen und Interaktion punktuell bleibt, ist die klassische Seite pro Navigation immer noch die beste Wahl — schnell, auffindbar, robust.

7:39 Für Kartenwerk gilt das für die gesamte öffentliche Seite. Und schauen Sie auf die Fußzeile: Modulare Frontends in einem Deployment sind der Mittelweg, der fast nie diskutiert wird. Sie bekommen Grenzen, ohne die Kosten der Verteilung zu bezahlen. Microfrontends lösen ein echtes Problem — aber ein organisatorisches. Wenn fünf Teams unabhängig ausliefern müssen, sind sie die Antwort.

8:01 Was dabei selten mitgerechnet wird, steht in den ersten beiden Punkten: Jedes Teil bringt seine eigenen Abhängigkeiten mit, und Ihre Nutzer laden im Zweifel dieselbe Bibliothek mehrfach. Das ist eine Rechnung, die Ihre Nutzer bezahlen, nicht Sie. Und der letzte Punkt ist die Prüffrage: Ohne getrennte Teams mit getrennten Releases bekommen Sie ausschließlich die Kosten.

8:23 Der zweite Punkt verdient Aufmerksamkeit, weil er so unauffällig passiert. Ein Backend for Frontend beginnt als dünne Anpassungsschicht und wächst über Monate zu einer zweiten Fachlogik heran — mit eigenen Regeln, die keiner Domänenentscheidung entsprechen. Ziehen Sie dort früh eine Grenze: Formen und Zusammenführen ja, Entscheiden nein.

8:41 Der dritte Punkt betrifft Kartenwerk direkt: Eine Anwendung im Browser, deren Inhalte über Suchmaschinen gefunden werden sollen, ist eine Entscheidung gegen das eigene Geschäftsmodell.

Mobile Bereitstellungsmodelle

8:52 Bleiben wir bei der Oberfläche, wechseln aber das Gerät. Am Veranstaltungsabend hat jeder Besucher von Kartenwerk ein Telefon in der Hand — und die Frage, was darauf läuft, ist erstaunlich selten eine technische. Vier Wege, dazu die Hybridform. Was diese Entscheidung so schwierig macht, ist nicht die Technik, sondern dass sie meist schon gefallen ist, bevor jemand sie diskutiert — weil „wir brauchen eine App" als Anforderung formuliert wird, nicht als Lösungsvorschlag.

9:19 Die Progressive Web Application ist dabei die Option, die am häufigsten übersehen wird: installierbar, offlinefähig, ohne den Weg über einen Store und ohne dessen Freigabezyklen. Für viele Anwendungsfälle ist sie näher am Bedarf als eine native App. Die vier Felder sortieren sich entlang von zwei Fragen: Wie tief brauchen Sie Zugriff auf das Gerät, und wie viele Codebasen wollen Sie pflegen?

9:42 Oben links ist der Aufwand am kleinsten, unten links am größten. Interessant ist das Feld unten rechts: Eine Codebasis für beide Plattformen klingt nach dem besten Kompromiss, verlagert aber Ihre Abhängigkeit — Sie hängen dann am Zwischenwerk und an dessen Tempo bei neuen Betriebssystemversionen. Das ist kein Argument dagegen, aber eines für eine bewusste Entscheidung.

10:03 Diese vier Fragen beantworten die Entscheidung fast vollständig, und keine davon ist eine Frage an Entwickler. Braucht es Gerätefunktionen, die der Browser nicht hergibt? Ist der Store Teil des Vertriebswegs? Wie oft wollen Sie ausliefern — und wer prüft dazwischen, denn eine Store-Freigabe dauert. Und die letzte Frage ist die architektonisch wichtigste: ein gemeinsames Backend oder je Oberfläche ein eigenes.

10:27 Beim Einlass von Kartenwerk lautet die Antwort eindeutig gemeinsam, denn dieselbe Buchung wird geprüft. Der dritte Punkt ist der, der Projekte wirklich in Schwierigkeiten bringt. Offline-Fähigkeit wird zugesagt, weil sie gut klingt, und erst Monate später merkt jemand, dass zwei Geräte denselben Datensatz verändert haben können.

10:46 Die Konfliktauflösung ist der schwierige Teil, nicht das Speichern. Und der letzte Punkt: Getrennte Backends für Web und App entstehen selten aus einer Entscheidung. Sie entstehen, weil zwei Teams parallel angefangen haben — und danach gibt es zwei Wahrheiten über dieselbe Fachlichkeit.

Praxisübung

11:03 Zeit für die Anwendung. Kartenwerk hat zwei Oberflächen, die unterschiedlicher kaum sein könnten — und genau deshalb verdienen sie zwei getrennte Entscheidungen. Halten Sie sich den Gegensatz vor Augen. Die öffentliche Veranstaltungssuche muss gefunden werden, wird von Fremden auf beliebigen Geräten geöffnet und erlebt extreme Lastspitzen.

11:23 Der Veranstalterbereich wird von wenigen Menschen täglich über Stunden benutzt, ist angemeldet und muss nirgends auffindbar sein. Wenn für zwei so verschiedene Fälle dieselbe Antwort herauskommt, ist das ein Hinweis darauf, dass nicht die Anforderungen entschieden haben, sondern die Gewohnheit. Nehmen Sie sich für jede Oberfläche drei Kriterien und benennen Sie ausdrücklich eine Alternative, die Sie verwerfen — mit dem Grund.

11:47 Das Erfolgskriterium verlangt zusätzlich etwas Konkretes: Sagen Sie, was auf einem drei Jahre alten Telefon beim Vorverkaufsstart passiert. Diese Frage zwingt Sie, die Theorie an einer realen Situation zu prüfen. Und sie ist keine Schikane — an einem Veranstaltungsabend steht genau dieses Gerät vor dem Einlass. Der erste Punkt ist der, den ich in Übungen am häufigsten sehe: Es wird eine Entscheidung für die ganze Anwendung getroffen, weil das ordentlicher wirkt.

12:14 Tatsächlich ist die Mischung der Normalfall — eine statische öffentliche Seite und eine Anwendung im Browser für den angemeldeten Bereich ist eine sehr gute Architektur. Und der zweite Punkt: Auffindbarkeit entsteht nicht dadurch, dass der Server irgendetwas rendert. Sie entsteht dadurch, dass der Inhalt in der ersten Antwort steht.

12:32 Im nächsten Modul geht es hinter die Oberfläche.