Architektur von Webanwendungen

In dieser Lerneinheit tauchst du in die grundlegende Architektur moderner Webanwendungen ein und verstehst das Client-Server-Modell als zentrales Konzept. Du lernst die verschiedenen Komponenten und deren Zusammenspiel kennen und erfährst, wie Thin Clients in der Praxis eingesetzt werden. Diese Grundlagen sind essentiell für deine spätere Entwicklungsarbeit und helfen dir, fundierte Architekturentscheidungen bei eigenen Webprojekten zu treffen.

Einführung

Moderne Webanwendungen bestehen aus vielen Komponenten, die zusammenarbeiten müssen. Ein Online-Shop zeigt Produkte an, verarbeitet Bestellungen und speichert Kundendaten. Aber wie ist das alles organisiert?

Chaos vs. Struktur: Links eine Webanwendung ohne klare Architektur, rechts die strukturierte Drei-Schichten-Architektur — Bildrechte: Ausbildung-in-der-IT.de (KI-unterstützt)

Ohne klare Architektur wird eine Webanwendung schnell unübersichtlich. Änderungen werden kompliziert, Fehler häufen sich und die Wartung wird zum Albtraum.

Die Architektur von Webanwendungen definiert, wie die verschiedenen Teile strukturiert und voneinander getrennt werden. Das Client-Server-Modell und die Drei-Schichten-Architektur sind dabei zentrale Konzepte, die du verstehen musst.

In dieser Lerneinheit lernst du, wie Webanwendungen aufgebaut sind, welche Rolle Client und Server spielen und wie du durch kluge Architekturentscheidungen wartbare und skalierbare Anwendungen entwickelst.

Lernziele

Nach dieser Lerneinheit kannst du:

• Das Client-Server-Modell erklären und die Rolle von Thin Clients verstehen
• Die Drei-Schichten-Architektur (Presentation, Application, Data Layer) beschreiben
• Statisches und dynamisches Content Serving unterscheiden
• Separation of Concerns und Entkopplung als Architekturprinzipien anwenden

Überleitung

Um zu verstehen, wie moderne Webanwendungen aufgebaut sind, beginnen wir mit dem Client-Server-Modell. Dieses fundamentale Konzept bildet die Grundlage für die Kommunikation zwischen Browser und Server.

Danach lernst du die Drei-Schichten-Architektur kennen und verstehst, wie Content statisch oder dynamisch ausgeliefert wird. Zum Abschluss erfährst du, wie Separation of Concerns und Entkopplung zu wartbaren Anwendungen führen.

Was ist das Client-Server-Modell?

Das Client-Server-Modell ist die Grundlage moderner Webanwendungen. Es definiert, wie zwei Hauptakteure zusammenarbeiten:

• Client: Ein System oder eine Software, die Dienste vom Server anfordert. In Webanwendungen ist der Browser der typische Client.

• Server: Ein System oder eine Software, die auf Anfragen von Clients wartet und darauf antwortet. Der Server verarbeitet die Anfragen und liefert die benötigten Daten oder Funktionen.

Die Kommunikation zwischen Client und Server erfolgt über das HTTP-Protokoll (Hypertext Transfer Protocol). HTTP definiert eine Anfrage-Antwort-Struktur: Der Client sendet eine Anfrage, der Server verarbeitet sie und schickt eine Antwort zurück.

Thin Clients verstehen

Ein Thin Client ist ein spezialisierter Client mit minimaler lokaler Verarbeitung. Die eigentliche Arbeit erledigt der Server.

Merkmale von Thin Clients:

• Geringer lokaler Speicherbedarf: Daten und Anwendungslogik liegen auf dem Server
• Minimale Datenverarbeitung: Der Client ist nur für Darstellung und Eingabe zuständig
• Abhängigkeit vom Server: Ohne Server-Verbindung kann der Client nicht arbeiten
• Einfache Wartung: Updates erfolgen zentral auf dem Server, nicht auf jedem Client

In Webanwendungen agiert der Browser als Thin Client. Er stellt Anfragen an den Server und zeigt die zurückgelieferten Informationen an. Die komplexe Verarbeitung (Datenbankzugriffe, Geschäftslogik) findet auf dem Server statt.

Vorteile der Client-Server-Architektur

Das Client-Server-Modell bietet entscheidende Vorteile für Webanwendungen:

• Zentrale Wartung und Updates: Die Anwendungslogik liegt auf dem Server. Änderungen werden an einer Stelle vorgenommen und sind sofort für alle Clients verfügbar.

• Skalierbarkeit: Bei steigender Last können zusätzliche Server hinzugefügt werden. Die Verteilung der Anfragen erfolgt automatisch durch Load Balancer.

• Plattformunabhängige Erreichbarkeit: Webanwendungen laufen in jedem modernen Browser, unabhängig vom Betriebssystem. Ein einziger Codebase bedient Windows, macOS, Linux und mobile Geräte.

• Effiziente Ressourcennutzung: Rechenintensive Operationen laufen auf leistungsstarken Servern, nicht auf den Clients.

Client-Server in der Praxis

E-Commerce-Plattformen: Der Kunde nutzt seinen Browser (Client), um Produkte anzusehen und in den Warenkorb zu legen. Die Verarbeitung erfolgt auf dem Server: Lagerüberprüfung, Preisberechnung und Bezahlvorgang. Der Browser zeigt nur die Ergebnisse an.

Online-Arbeitsumgebungen: Werkzeuge wie Google Docs nutzen die Client-Server-Architektur optimal. Die Dokumentenverarbeitung und Speicherung erfolgt auf Google-Servern. Der Browser dient nur als Eingabe- und Darstellungsschicht.

Der Browser als Thin Client ermöglicht eine effiziente Serverressourcen-Nutzung und vereinfacht die Wartung der Anwendung erheblich.

Die Drei-Schichten-Architektur

Die Drei-Schichten-Architektur (Three-Tier Architecture) ist ein etabliertes Designmuster für Webanwendungen. Sie teilt die Anwendung in drei klar getrennte Schichten:

• Presentation Layer (Präsentationsschicht): Zuständig für die Darstellung und Benutzerinteraktion. Hier wird definiert, wie die Anwendung aussieht und wie Nutzer mit ihr interagieren.

• Application Layer (Anwendungsschicht): Enthält die Geschäftslogik der Anwendung. Hier werden Eingaben verarbeitet, Berechnungen durchgeführt und Entscheidungen getroffen.

• Data Layer (Datenschicht): Verwaltet die Datenpersistenz. Hier werden Daten gespeichert, gelesen, geändert und gelöscht.

Die Trennung in Schichten fördert Wartbarkeit, Skalierbarkeit und Wiederverwendbarkeit des Codes.

Layer vs Tier: Ein wichtiger Unterschied

In der Fachliteratur werden Layer (Schicht) und Tier oft synonym verwendet. Es gibt jedoch einen wichtigen Unterschied:

• Layer (Schicht): Bezieht sich auf die logische Trennung im Code. Die drei Schichten können alle auf einem einzigen Server laufen. Es geht um die Code-Struktur, nicht um die physische Verteilung.

• Tier: Bezeichnet die physische Trennung auf separate Server oder Hardware. Eine “Three-Tier”-Anwendung läuft auf drei verschiedenen Servern (Webserver, Applikationsserver, Datenbankserver).

Beispiel: Eine “Three-Layer-Anwendung” kann als “Single-Tier” (alles auf einem Server) oder “Three-Tier” (drei separate Server) deployed werden. Die logische Architektur (Layer) bleibt gleich.

In dieser Lerneinheit fokussieren wir auf die logische Schichtenarchitektur (Layers).

Presentation Layer im Detail

Der Presentation Layer ist für die Benutzerschnittstelle zuständig:

Hauptaufgaben:

• Daten an den Benutzer präsentieren
• Benutzereingaben entgegennehmen
• Diese Eingaben an die nächste Schicht weiterleiten

Technologien (Beispiele):

• HTML und CSS für Struktur und Design
• JavaScript für Interaktivität
• Frameworks wie React oder Vue.js für dynamische Anwendungen

In modernen Webanwendungen läuft der Presentation Layer im Browser des Benutzers.

Der Presentation Layer enthält keine Geschäftslogik und greift nicht direkt auf Datenbanken zu. Er kommuniziert ausschließlich mit dem Application Layer.

Application Layer im Detail

Der Application Layer implementiert die Geschäftslogik:

Hauptaufgaben:

• Benutzereingaben vom Presentation Layer verarbeiten
• Geschäftsregeln anwenden und Berechnungen durchführen
• Entscheidungen treffen (z.B. “Ist der Benutzer berechtigt?“)
• Mit dem Data Layer interagieren, um Daten zu speichern oder abzurufen

Technologien (Beispiele):

• Serverseitige Sprachen wie PHP, Java oder Python
• Frameworks wie Node.js/Express oder Django für strukturierte Entwicklung

Der Application Layer ist das “Gehirn” der Anwendung. Hier findet die eigentliche Verarbeitung statt.

Durch die Trennung vom Presentation Layer kann die Geschäftslogik unabhängig von der Benutzeroberfläche entwickelt und getestet werden.

Data Layer im Detail

Der Data Layer kümmert sich um die Datenverwaltung:

Hauptaufgaben:

• Daten persistent speichern (in Datenbanken)
• Daten lesen, ändern und löschen (CRUD-Operationen)
• Datenkonsistenz und -integrität sicherstellen

Technologien (Beispiele):

• Relationale Datenbanken wie MySQL oder PostgreSQL für strukturierte Daten
• NoSQL-Datenbanken wie MongoDB für unstrukturierte Daten
• ORMs (Object-Relational Mapping) wie Sequelize oder Hibernate als Brücke zwischen Objekten und Datenbank

Der Data Layer agiert als Bindeglied zwischen der Anwendungslogik und der eigentlichen Datenquelle.

Wichtig: Der Data Layer sollte nur über den Application Layer angesprochen werden, niemals direkt vom Presentation Layer.

Drei-Schichten in der Praxis: Buchgeschäft

Schauen wir uns ein konkretes Beispiel an:

Szenario: Du entwickelst eine Webanwendung für ein Buchgeschäft.

• Presentation Layer: Die Webseite zeigt verfügbare Bücher mit Bildern, Preisen und Beschreibungen. Der Nutzer kann Bücher auswählen und in den Warenkorb legen. HTML/CSS/JavaScript sorgen für eine ansprechende Darstellung.

• Application Layer: Wenn der Nutzer ein Buch kaufen möchte, verarbeitet dieser Layer die Anfrage: Ist das Buch verfügbar? Ist der Preis korrekt? Hat der Nutzer genug Guthaben? Die Geschäftslogik trifft diese Entscheidungen.

• Data Layer: Die Verfügbarkeit wird in der Datenbank geprüft. Nach erfolgreichem Kauf wird der Lagerbestand aktualisiert und die Bestellung gespeichert.

Die klare Trennung ermöglicht es verschiedenen Entwicklern, unabhängig an unterschiedlichen Teilen zu arbeiten.

⏳ Lädt Dataview-Inhalt...

Statisches Content Serving

Statisches Content Serving bezieht sich auf Inhalte, die sich nicht ändern, sobald sie auf den Server hochgeladen wurden. Typische Beispiele sind Bilder, CSS-Dateien oder JavaScript-Dateien.

Hauptvorteil: Die Schnelligkeit der Auslieferung. Statische Inhalte werden direkt vom Server geladen, ohne dass eine serverseitige Verarbeitung notwendig ist.

Beispiel: Eine HTML-Seite mit eingebundenen Bildern und Stylesheets wird unverändert an jeden Benutzer ausgeliefert:

<!DOCTYPE html>
<html>
<head>
    <link rel="stylesheet" href="styles.css">
</head>
<body>
    <img src="logo.png" alt="Logo">
    <p>Willkommen auf unserer Webseite!</p>
</body>
</html>

Jeder Nutzer erhält exakt dieselbe HTML-Datei, dasselbe Bild und dieselbe CSS-Datei.

Dynamisches Content Serving

Dynamisches Content Serving generiert oder modifiziert Inhalte in Echtzeit, bevor sie an den Benutzer ausgeliefert werden. Dies ermöglicht personalisierte und interaktive Benutzererfahrungen.

Dynamisches Content Serving nutzt serverseitige Skripte in Sprachen wie PHP, Java, Python oder JavaScript (Node.js).

Beispiel: Eine Webseite begrüßt den Benutzer persönlich:

<?php
$benutzername = htmlspecialchars($_GET["benutzername"]);
echo "Hallo, " . $benutzername . "! Willkommen zurück auf unserer Webseite.";
?>

Wichtig: Die Funktion htmlspecialchars() schützt vor XSS-Angriffen (Cross-Site Scripting), indem sie Sonderzeichen wie < und > in sichere HTML-Entities umwandelt.

Jeder Nutzer erhält eine individuell generierte Seite mit seinem Namen.

Static vs Dynamic: Der Vergleich

Die Wahl zwischen statischem und dynamischem Content Serving hängt von den Anforderungen ab:

Kriterium	Statisches Serving	Dynamisches Serving
Inhaltsänderung	Bei Upload auf Server	Bei jeder Anfrage
Personalisierung	Nicht möglich	Hochgradig möglich
Serverlast	Gering	Höher (abhängig von Anfrage)
Entwicklungskomplexität	Einfacher	Komplexer
Geschwindigkeit	Sehr schnell	Langsamer (Verarbeitung nötig)

Moderne Webanwendungen kombinieren meist beide Ansätze: Statische Inhalte (CSS, Bilder) für Performance und dynamische Inhalte für Interaktivität.

Warum die Unterscheidung wichtig ist

Das Verständnis von statischem und dynamischem Content Serving hilft dir bei wichtigen Entscheidungen:

Performance-Optimierung: Statische Inhalte können durch Caching noch schneller ausgeliefert werden. Der Browser speichert CSS, Bilder und JavaScript lokal und muss sie nicht bei jedem Besuch neu laden.

Content Delivery Networks (CDN): Statische Dateien können auf CDN-Server weltweit verteilt werden. Nutzer laden dann von einem Server in ihrer Nähe, was die Ladezeit drastisch reduziert.

Anwendungsentscheidung:

• Statisch: Einfache Informationswebsites, Dokumentation, Blogs (mit statischen Generatoren)
• Dynamisch: Online-Shops, Social Media, Dashboards, personalisierte Anwendungen
• Hybrid: Die meisten modernen Webanwendungen nutzen statisches Serving für Assets und dynamisches Serving für Daten.

Separation of Concerns Prinzip

Separation of Concerns (SoC) ist ein fundamentales Designprinzip in der Softwareentwicklung:

Grundidee: Ein Programm wird in verschiedene Abschnitte unterteilt, wobei jeder Abschnitt ein bestimmtes “Anliegen” (Concern) adressiert. Das Ziel ist es, die Komplexität zu verringern.

Warum ist SoC wichtig?

• Wartbarkeit: Code für unterschiedliche Funktionen ist getrennt und leichter zu verstehen, anpassen und zu debuggen
• Erweiterbarkeit: Neue Funktionen können hinzugefügt werden, ohne bestehende Codeabschnitte wesentlich zu verändern
• Wiederverwendbarkeit: Durch die Trennung können einzelne Module in anderen Projekten wiederverwendet werden
• Parallele Entwicklung: Verschiedene Teams können gleichzeitig an unterschiedlichen Teilen arbeiten

Separation of Concerns reduziert die Kopplung zwischen Komponenten und erhöht die Kohäsion innerhalb einer Komponente.

SoC in Webanwendungen umsetzen

In Webanwendungen wird Separation of Concerns durch die Trennung von Frontend und Backend umgesetzt:

Frontend (Präsentationsschicht)	Backend (Logik- und Datenzugriffsschicht)
Zuständig für die Darstellung	Geschäftslogik der Anwendung
Strukturierung mit HTML	Datenzugriff und Persistenz
Design mit CSS	Performance-Optimierung
Verhalten mit JavaScript
Fokus: Wie sieht die Anwendung aus? Wie interagiert der Nutzer?	Fokus: Wie funktioniert die Anwendung? Welche Regeln gelten?

Die klare Trennung ermöglicht es, Frontend und Backend unabhängig voneinander zu entwickeln, zu testen und zu aktualisieren. Das Frontend kann komplett neu gestaltet werden, ohne das Backend ändern zu müssen.

Entkopplung verstehen

Entkopplung (Decoupling) geht Hand in Hand mit Separation of Concerns:

Definition: Entkopplung bedeutet, Abhängigkeiten zwischen verschiedenen Teilen einer Anwendung zu reduzieren. Ein gut entkoppelter Code hat nur minimale Verbindungen zu anderen Code-Teilen.

Vorteile:

Vorteil	Beschreibung
Änderungen sind einfacher	Wenn Komponente A entkoppelt von Komponente B ist, kann A geändert werden, ohne B anzupassen
Fehlerbehebung wird leichter	Fehler in einer Komponente breiten sich nicht auf andere aus
Testing wird einfacher	Komponenten können isoliert getestet werden
Austauschbarkeit	Einzelne Komponenten können durch alternative Implementierungen ersetzt werden

Je enger Komponenten gekoppelt sind, desto schwieriger wird die Wartung. Entkopplung ist ein Schlüssel zu flexiblen, robusten Anwendungen.

Entkopplung praktisch umsetzen

Es gibt mehrere etablierte Techniken zur Entkopplung:

1. APIs (Application Programming Interfaces): Eine wohldefinierte Schnittstelle verbindet Frontend und Backend. Änderungen auf einer Seite beeinflussen die andere nicht, solange die API gleich bleibt.

2. Microservices: Statt einer monolithischen Architektur wird die Anwendung in kleinere, unabhängige Dienste aufgeteilt. Jeder Service ist eigenständig und kommuniziert über APIs mit anderen.

3. Design Patterns:

• Repository Pattern: Abstrahiert den Datenzugriff vom Rest der Anwendung
• Observer Pattern: Komponenten können Ereignisse abonnieren, ohne direkt gekoppelt zu sein
• Dependency Injection: Abhängigkeiten werden von außen übergeben statt intern erzeugt

Die Wahl der Entkopplungstechnik hängt von der Größe und Komplexität der Anwendung ab.

E-Commerce mit entkoppelter Architektur

Schauen wir uns ein praktisches Beispiel an:

E-Commerce-System mit Service-Architektur:

Frontend: Eine React-Webanwendung zeigt Produktlisten, Warenkorb und Checkout-Prozess an. Das Frontend kommuniziert ausschließlich über APIs mit den Backend-Services.

Backend-Service: Produktmanagement: Ein eigenständiger Microservice verwaltet alle Produkt-Daten (Hinzufügen, Ändern, Löschen). Er hat seine eigene Datenbank und kann unabhängig aktualisiert werden.

Backend-Service: Bestellmanagement: Ein weiterer Microservice verarbeitet Bestellungen, prüft Lagerbestände (über API vom Produktmanagement) und koordiniert den Checkout.

Vorteile dieser Entkopplung:

• Das Frontend kann komplett neu gestaltet werden (z.B. als mobile App), ohne die Backend-Services zu ändern
• Jeder Service kann in einer anderen Technologie entwickelt werden
• Services sind unabhängig skalierbar
• Fehler in einem Service betreffen nicht die anderen

Diese Architektur ermöglicht es verschiedenen Teams, parallel und unabhängig zu arbeiten.

⏳ Lädt Dataview-Inhalt...

Zusammenfassung und Ausblick

Zusammenfassung

Client-Server-Architektur bildet die Grundlage moderner Webanwendungen. Der Client (Browser) stellt Anfragen via HTTP, der Server verarbeitet diese und sendet Antworten zurück. Thin Clients verlagern die Verarbeitung auf den Server und ermöglichen zentrale Verwaltung.

Die Drei-Schichten-Architektur strukturiert Webanwendungen in:

Schicht	Aufgabe	Technologien
Presentation Layer	Darstellung und Benutzerinteraktion	HTML, CSS, JavaScript, React
Application Layer	Geschäftslogik und Datenverarbeitung	PHP, Node.js, Python
Data Layer	Datenpersistenz und -verwaltung	MySQL, PostgreSQL, MongoDB

Layer vs Tier: Layer beschreiben die logische Trennung im Code, Tier die physische Verteilung auf Server. Eine Drei-Layer-Architektur kann als One-Tier (alles auf einem Server) oder Three-Tier (drei separate Server) betrieben werden.

Statisches Content Serving liefert unveränderte Dateien schnell aus (HTML, CSS, Bilder). Dynamisches Content Serving generiert Inhalte in Echtzeit basierend auf Benutzereingaben und ermöglicht Personalisierung.

Separation of Concerns trennt unterschiedliche Anliegen in separate Module. Entkopplung reduziert Abhängigkeiten zwischen Komponenten durch APIs, Microservices und Design Patterns. Diese Prinzipien fördern Wartbarkeit, Erweiterbarkeit und Wiederverwendbarkeit.

Ausblick

Du verstehst jetzt die grundlegende Architektur von Webanwendungen. In der nächsten Lerneinheit Einführung in Webanwendungen lernst du die praktische Umsetzung dieser Konzepte kennen: Wie HTML, CSS und JavaScript im Browser zusammenarbeiten, wie HTTP-Anfragen konkret ablaufen und welche Rolle Webserver und Application Server spielen.

---