System Design for Frontend Developers - Architecting Scalable UIs, State, and Data Layers

Datenarchitektur in modernen Frontends

Eine skalierbare Frontend-Anwendung benötigt eine klare Strategie für den Umgang mit Daten. Viele Probleme großer Anwendungen entstehen nicht durch die Oberfläche selbst, sondern durch schlecht organisierte Datenflüsse.

Eine gute Datenarchitektur beantwortet wichtige Fragen:

• Woher kommen Daten?

• Wer ist für deren Verarbeitung verantwortlich?

• Wie werden Daten zwischengespeichert?

• Wann werden Daten aktualisiert?

• Was passiert bei Fehlern?

• Wie werden verschiedene Teile der Anwendung synchron gehalten?

Das Ziel ist nicht nur, Daten anzeigen zu können. Das Ziel ist ein vorhersehbares System, bei dem Entwickler jederzeit verstehen können, wie Informationen durch die Anwendung fließen.

Datenfluss als zentrales Architekturprinzip

Ein klarer Datenfluss ist eine der wichtigsten Grundlagen skalierbarer Anwendungen.

Wenn Daten unkontrolliert zwischen Komponenten weitergegeben werden, entstehen schwer nachvollziehbare Abhängigkeiten.

Beispiel eines problematischen Ansatzes:

Eine Komponente lädt Daten.
Eine zweite Komponente verändert diese Daten.
Eine dritte Komponente erwartet eine bestimmte Struktur.
Eine vierte Komponente aktualisiert denselben Zustand.

Mit zunehmender Größe wird dieses System schwer kontrollierbar.

Ein besserer Ansatz:

• Daten werden an definierten Stellen geladen.

• Zuständigkeiten sind klar getrennt.

• Komponenten erhalten nur die Informationen, die sie benötigen.

• Änderungen erfolgen über definierte Schnittstellen.

Dadurch wird der Datenfluss nachvollziehbar.

API-Integration und Datenzugriff

Frontend-Anwendungen sind meistens von mehreren externen Quellen abhängig.

Beispiele:

• Backend-APIs

• Authentifizierungsdienste

• Zahlungsanbieter

• Suchsysteme

• Analyseplattformen

Eine häufige Fehlentscheidung ist, API-Aufrufe direkt in beliebige Komponenten einzubauen.

Das führt zu:

• doppeltem Code

• schwer testbaren Komponenten

• schlechter Fehlerbehandlung

• unklaren Verantwortlichkeiten

Eine bessere Architektur trennt den Datenzugriff von der Benutzeroberfläche.

Die UI beschreibt:

Was soll angezeigt werden?

Die Datenebene beschreibt:

Wie werden die Informationen beschafft?

Data Access Layer

Ein Data Access Layer bildet eine Abstraktionsschicht zwischen Anwendung und externen Datenquellen.

Seine Aufgaben:

• API-Aufrufe kapseln

• Daten transformieren

• Fehler standardisieren

• Wiederverwendung ermöglichen

Beispiel:

Statt überall direkt eine Benutzer-API aufzurufen:

fetch("/api/users")

verwendet die Anwendung eine zentrale Funktion:

getUsers()

Der Vorteil:

Wenn sich später die API ändert, muss nur eine Stelle angepasst werden.

Caching als wichtiger Bestandteil der Architektur

Caching ist nicht nur eine Performance-Technik.

Es ist eine Architekturentscheidung.

Eine Anwendung muss entscheiden:

• Welche Daten bleiben gespeichert?

• Wie lange sind sie gültig?

• Wann müssen sie aktualisiert werden?

• Wie erkennt das System veraltete Daten?

Ohne klare Strategie entstehen Probleme.

Beispiele:

• Nutzer sehen alte Informationen.

• Daten werden unnötig häufig geladen.

• Verschiedene Komponenten zeigen unterschiedliche Zustände.

Verschiedene Cache-Strategien

Temporäres Caching

Daten werden für eine bestimmte Zeit gespeichert.

Geeignet für:

• Produktlisten

• öffentliche Inhalte

• Suchergebnisse

Vorteil:

Weniger Netzwerkzugriffe.

Nachteil:

Daten können kurzzeitig veraltet sein.

Stale-While-Revalidate

Eine moderne Strategie:

Die Anwendung zeigt vorhandene Daten sofort an und aktualisiert sie im Hintergrund.

Ablauf:

1. Vorhandene Daten werden angezeigt.

2. Neue Daten werden geladen.

3. Die Oberfläche wird aktualisiert.

Der Nutzer erlebt eine schnelle Anwendung, während die Daten aktuell bleiben.

Optimistisches Update

Bei bestimmten Aktionen wird die Oberfläche sofort aktualisiert, bevor der Server bestätigt.

Beispiel:

Ein Nutzer markiert eine Aufgabe als erledigt.

Die Oberfläche zeigt sofort den neuen Zustand.

Danach wird die Serverantwort geprüft.

Vorteil:

Sehr schnelle Benutzererfahrung.

Nachteil:

Fehler müssen sauber behandelt werden.

Fehlerbehandlung in Frontend-Systemen

Fehler sind kein Ausnahmefall.

In großen Anwendungen gehören Fehler zum normalen Betrieb.

Eine robuste Architektur berücksichtigt:

• Netzwerkfehler

• ungültige Daten

• abgelaufene Sessions

• Berechtigungsprobleme

• Serverfehler

Eine schlechte Anwendung zeigt häufig nur:

"Etwas ist schiefgelaufen."

Eine gute Anwendung unterscheidet:

• Was ist passiert?

• Kann der Nutzer etwas tun?

• Kann das System automatisch reagieren?

Fehlerzustände als Teil des Designs

Jede datenabhängige Oberfläche sollte verschiedene Zustände berücksichtigen.

Dazu gehören:

Loading State

Was sieht der Nutzer während des Ladens?

Mögliche Lösungen:

• Skeleton Screens

• Ladeindikatoren

• optimistische Darstellung

Empty State

Was passiert, wenn keine Daten existieren?

Beispiel:

Eine Aufgabenliste ohne Aufgaben sollte nicht wie ein Fehler aussehen.

Error State

Was passiert, wenn etwas nicht funktioniert?

Der Nutzer sollte eine verständliche Information und möglichst eine Handlungsmöglichkeit erhalten.

Performance als Architekturthema

Performance wird häufig erst betrachtet, wenn eine Anwendung langsam wird.

Das Buch zeigt jedoch, dass Performance bereits bei Architekturentscheidungen beginnt.

Eine schlechte Struktur führt später zu:

• unnötigen Berechnungen

• großen JavaScript-Bundles

• langsamen Ladezeiten

• schlechter Benutzererfahrung

Komponenten-Performance

Kleine, klar getrennte Komponenten erleichtern Optimierungen.

Probleme entstehen häufig durch:

• unnötige Re-Renders

• zu große Komponenten

• globale Zustände mit vielen Abhängigkeiten

Eine gute Architektur reduziert diese Probleme automatisch.

Code Splitting

Nicht jeder Nutzer benötigt sofort den gesamten Anwendungscode.

Code Splitting teilt die Anwendung in kleinere Pakete.

Beispiel:

Ein Administrationsbereich muss nicht geladen werden, wenn ein normaler Nutzer nur die Startseite besucht.

Vorteile:

• schnellerer Start

• kleinere initiale Dateien

• bessere Nutzererfahrung

Lazy Loading

Bestimmte Inhalte werden erst geladen, wenn sie benötigt werden.

Beispiele:

• große Dialoge

• selten verwendete Funktionen

• komplexe Diagramme

Das reduziert die anfängliche Belastung.

Rendering-Strategien

Moderne Frontends bieten verschiedene Möglichkeiten, Inhalte zu erzeugen.

Client-Side Rendering

Die Oberfläche wird hauptsächlich im Browser aufgebaut.

Vorteile:

• einfache Interaktion

• gute Möglichkeiten für dynamische Anwendungen

Nachteile:

• längere Ladezeit beim ersten Aufruf

Server-Side Rendering

Die Anwendung erzeugt HTML bereits auf dem Server.

Vorteile:

• schneller erster Inhalt

• Vorteile für Suchmaschinen

Nachteile:

• komplexere Architektur

Static Generation

Inhalte werden vorab erzeugt.

Geeignet für:

• Dokumentationen

• Marketingseiten

• selten veränderte Inhalte

Eine gute Architektur entscheidet abhängig vom Anwendungsfall.

Skalierung im Team

Eine Anwendung muss nicht nur technisch skalieren.

Sie muss auch organisatorisch skalieren.

Bei größeren Teams entstehen Probleme durch:

• unterschiedliche Arbeitsweisen

• uneinheitliche Komponenten

• verschiedene Qualitätsstandards

Deshalb benötigt ein Team:

• klare Architekturregeln

• gemeinsame Konventionen

• dokumentierte Entscheidungen

• wiederverwendbare Muster

Architekturentscheidungen und Trade-offs

Das Buch betont, dass es keine perfekte Architektur gibt.

Jede Entscheidung besitzt Vor- und Nachteile.

Beispiele:

Mehr Abstraktion:

Vorteile:

• mehr Wiederverwendung

• weniger doppelter Code

Nachteile:

• höhere Komplexität

Mehr Zentralisierung:

Vorteile:

• einfacher Überblick

Nachteile:

• mehr Abhängigkeiten

Mehr Modularität:

Vorteile:

• unabhängige Entwicklung

Nachteile:

• zusätzlicher Kommunikationsaufwand

Gute Architektur bedeutet deshalb nicht maximale Komplexität, sondern passende Komplexität.

Verbindung zwischen den zentralen Konzepten

Die einzelnen Themen des Buches sind nicht unabhängig voneinander zu betrachten. Eine skalierbare Frontend-Architektur entsteht erst durch das Zusammenspiel aller Bereiche.

Eine Anwendung kann beispielsweise eine gute Komponentenstruktur besitzen, aber trotzdem schwer wartbar sein, wenn der Datenfluss unklar ist. Ebenso kann ein perfektes State-Management-System keine schlechte UI-Architektur ausgleichen.

Die wichtigsten Zusammenhänge:

Komponentenarchitektur und State Management

Die Struktur der Komponenten beeinflusst direkt den Umgang mit Zuständen.

Wenn Komponenten zu viele Aufgaben übernehmen, entsteht häufig ein zu großer State.

Beispiel:

Eine große Dashboard-Komponente verwaltet:

• Benutzerinformationen

• Filter

• Tabellenzustand

• Einstellungen

• Benachrichtigungen

Mit der Zeit wird diese Komponente schwer verständlich.

Eine bessere Lösung ist die Aufteilung:

• Filter-Komponente verwaltet Filterzustand.

• Tabelle verwaltet Darstellungszustände.

• Benutzerbereich verwaltet Benutzerdaten.

Dadurch bleibt State dort, wo er benötigt wird.

Das zentrale Prinzip:

State sollte so nah wie möglich an seiner Verwendung liegen und nur dann geteilt werden, wenn mehrere Bereiche ihn wirklich benötigen.

State Management und Datenarchitektur

Viele Probleme entstehen, wenn Entwickler Serverdaten und UI-Zustände vermischen.

Beispiel:

Ein Nutzerprofil kommt aus einer API.

Dieses Profil ist kein klassischer UI-State.

Es besitzt eigene Eigenschaften:

• Es kann veraltet sein.

• Es kann aktualisiert werden.

• Es kann von mehreren Stellen benötigt werden.

• Es kann Fehler verursachen.

Deshalb sollte Server-State anders behandelt werden als lokaler Zustand.

Eine moderne Architektur trennt:

UI-State

Beispiele:

• geöffnetes Menü

• aktiver Tab

• Formularstatus

Application-State

Beispiele:

• angemeldeter Nutzer

• Sprache

• globale Einstellungen

Server-State

Beispiele:

• Produkte

• Bestellungen

• Nachrichten

Diese Trennung verhindert unnötige Komplexität.

Datenarchitektur und Performance

Die Art, wie Daten geladen und gespeichert werden, beeinflusst direkt die Geschwindigkeit einer Anwendung.

Ein schlechtes Muster:

Eine Seite lädt alle Daten beim Start.

Folgen:

• lange Ladezeiten

• unnötige Datenübertragung

• schlechte mobile Nutzung

Eine bessere Strategie:

• nur benötigte Daten laden

• Daten zwischenspeichern

• Inhalte verzögert laden

• Hintergrundaktualisierung verwenden

Performance entsteht also nicht nur durch Optimierungen im Code, sondern durch gute Systementscheidungen.

Architektur und Entwicklererfahrung

Ein wichtiges Thema ist Developer Experience.

Eine gute Architektur verbessert nicht nur die Anwendung, sondern auch die Arbeit der Entwickler.

Eine schlechte Architektur erzeugt Fragen:

• Wo gehört diese Funktion hin?

• Welche Komponente soll ich verwenden?

• Darf ich diesen State global machen?

• Wie teste ich diese Funktion?

Eine gute Architektur beantwortet diese Fragen durch klare Regeln.

Dadurch entsteht:

• schnellere Entwicklung

• weniger Fehler

• bessere Zusammenarbeit

• einfachere Einarbeitung neuer Teammitglieder

Praktische Anwendung im Projektalltag

Die Konzepte des Buches lassen sich in verschiedenen Entwicklungsphasen anwenden.

Bei neuen Projekten

Bereits am Anfang sollten grundlegende Entscheidungen getroffen werden.

Wichtige Fragen:

• Wie werden Komponenten organisiert?

• Wie werden Daten geladen?

• Welche Zustände existieren?

• Welche Bereiche gehören zusammen?

• Welche Standards gelten für das Team?

Eine frühe Architektur verhindert spätere Umbauten.

Bei bestehenden Anwendungen

Auch ältere Anwendungen können schrittweise verbessert werden.

Ein sinnvoller Ansatz:

Schritt 1: Abhängigkeiten analysieren

Identifizieren:

• besonders große Komponenten

• wiederholten Code

• unklare Datenflüsse

• globale Zustände ohne klare Verantwortung

Schritt 2: Grenzen definieren

Bereiche voneinander trennen:

• UI

• Logik

• Datenzugriff

• Services

Schritt 3: Schrittweise verbessern

Nicht die gesamte Anwendung neu schreiben.

Besser:

• einzelne Bereiche modernisieren

• neue Funktionen nach den neuen Standards entwickeln

• alte Bereiche schrittweise ersetzen

Architektur-Checkliste für skalierbare Frontends

UI-Architektur

• Hat jede Komponente eine klare Verantwortung?

• Sind Komponenten klein genug, um verstanden zu werden?

• Werden wiederverwendbare Bausteine zentral gepflegt?

• Ist die Kommunikation zwischen Komponenten klar definiert?

• Werden Darstellung und Geschäftslogik getrennt?

State Management

• Ist lokaler State wirklich lokal?

• Werden globale Zustände sparsam verwendet?

• Sind Serverdaten getrennt von UI-State?

• Gibt es klare Regeln für State-Aktualisierungen?

• Werden unnötige Kopien von Daten vermieden?

Datenarchitektur

• Gibt es eine klare Schicht für Datenzugriff?

• Sind API-Aufrufe zentral organisiert?

• Werden Fehler einheitlich behandelt?

• Gibt es eine Strategie für Caching?

• Ist klar definiert, wann Daten aktualisiert werden?

Performance

• Werden nur benötigte Daten geladen?

• Gibt es Code Splitting?

• Werden große Komponenten verzögert geladen?

• Werden unnötige Renderprozesse vermieden?

• Sind Ladezustände optimiert?

Team und Wartbarkeit

• Gibt es Architekturregeln?

• Werden Entscheidungen dokumentiert?

• Gibt es gemeinsame Standards?

• Können neue Entwickler schnell produktiv werden?

• Wird technische Qualität regelmäßig überprüft?

Wichtigste Erkenntnisse

Die wichtigsten Erkenntnisse des Buches lassen sich in mehreren Prinzipien zusammenfassen.

Frontends sind komplexe Systeme

Eine moderne Webanwendung besteht nicht nur aus Komponenten. Sie ist ein System aus UI, Daten, Zuständen und Kommunikation.

Architekturentscheidungen bestimmen, wie gut dieses System langfristig funktioniert.

Gute Grenzen schaffen Skalierbarkeit

Die wichtigste Aufgabe einer Architektur ist es, klare Grenzen zu schaffen.

Komponenten, Daten und Zustände sollten klar definierte Verantwortlichkeiten besitzen.

Weniger globale Komplexität

Nicht alles muss zentral verwaltet werden.

Lokale Lösungen sind häufig einfacher und robuster.

Globalisierung sollte nur entstehen, wenn ein echter Bedarf besteht.

Daten sind ein eigener Architekturbereich

Serverdaten unterscheiden sich fundamental von UI-Zuständen.

Eine klare Trennung verhindert viele typische Probleme moderner Anwendungen.

Performance beginnt bei der Planung

Schnelle Anwendungen entstehen nicht durch einzelne Optimierungen.

Sie entstehen durch:

• gute Datenstrategien

• passende Rendering-Entscheidungen

• kleine Komponenten

• effiziente Architektur

Die beste Architektur ist nicht die komplizierteste

Eine gute Architektur löst konkrete Probleme.

Sie sollte:

• verständlich

• erweiterbar

• wartbar

• anpassbar

sein.

Nicht jede Anwendung benötigt die gleiche Struktur.

Die richtige Architektur ist immer abhängig von:

• Größe des Projekts

• Anzahl der Entwickler

• Komplexität der Anforderungen

• langfristigen Zielen

Zusammenfassung in einem Satz

System Design für Frontend-Entwickler bedeutet, Anwendungen nicht mehr als Sammlung einzelner Komponenten zu betrachten, sondern als skalierbare Systeme aus UI, Zuständen und Datenflüssen zu entwerfen, deren Struktur langfristige Entwicklung ermöglicht.