Seminar NestJS – WebSockets und Echtzeitkommunikation

Echtzeitkommunikation hält Verbindungen über längere Zeit offen und verändert Sicherheits-, Zustands- und Betriebsanforderungen. Ein erfolgreicher Handshake garantiert weder dauerhaft gültige Berechtigungen noch zuverlässige Zustellung.

Der Kurs entwickelt ein Gateway als dünnen Transportadapter. Fachliche Ereignisse, Präsenz, Räume und Nachrichtenverträge werden getrennt modelliert; Skalierung und Wiederanlauf werden von Beginn an berücksichtigt.

Inhaltsübersicht

• Lernziele
• Gateway-Architektur und Ereignisverträge
• Authentifizierung und Autorisierung
• Zustand, Räume und zuverlässige Interaktion
• Skalierung, Backpressure und Betrieb
• Automatisierte Tests für Echtzeitabläufe
• Praxisprojekt: Live-Dashboard mit Benachrichtigungen
• Prüfpunkte und typische Fehler

Lernziele

• Gateway, Adapter, Verbindungslebenszyklus und Ereignisverträge strukturiert aufbauen.
• Verbindungsaufbau und einzelne Nachrichten sicher authentifizieren und autorisieren.
• Räume, Präsenz, Zustände und fachliche Ereignisse konsistent modellieren.
• Reconnect, Heartbeats, Zeitüberschreitungen, Bestätigungen und verpasste Ereignisse definieren.
• Mehrere Instanzen über gemeinsamen Adapter oder Broker skalieren.
• Gateway-, Client- und Mehrinstanz-Szenarien automatisiert testen.

Gateway-Architektur und Ereignisverträge

Das Gateway übersetzt Transportereignisse in Anwendungsbefehle und fachliche Ausgaben. Fachlogik bleibt in Services und kann unabhängig vom Protokoll getestet werden.

1. Echtzeit-Anwendungsfälle und notwendige Zustellcharakteristik erfassen.
2. Gateway in ein fachliches Modul integrieren und Application Services injizieren.
3. Ereignisnamen, Payload-Schemata, Versionen und Fehlerantworten definieren.
4. Eingehende Payloads validieren und unbekannte Felder kontrollieren.
5. Bestätigungen für kritische Nachrichten und Fire-and-forget für optionale Updates unterscheiden.
6. HTTP- und WebSocket-Zugriffe auf gemeinsame Fachservices ausrichten.

Entscheidungskriterien und Hinweise

• Gateway-Code bleibt ein Transportadapter und enthält keine umfangreiche Fachlogik.
• Ereignisverträge sind versioniert und unabhängig von internen Datenmodellen.

Authentifizierung und Autorisierung

Die Identität wird beim Verbindungsaufbau geprüft, kann aber während einer langen Verbindung ablaufen oder gesperrt werden. Berechtigungen werden zusätzlich pro Aktion und Raum bewertet.

1. Token aus einem kontrollierten Handshake-Feld lesen und validieren.
2. Verbindungsidentität serverseitig mit minimalen Claims speichern.
3. Ablauf, Rotation, Sperrung und erzwungenen Verbindungsabbau definieren.
4. Raumbeitritt und Nachrichtenversand mit fachlichen Policies prüfen.
5. Mandanten- und Objektgrenzen auch bei Broadcasts einhalten.
6. Fehlerantworten vereinheitlichen und sensible Gründe nicht offenlegen.
7. Verbindungs- und Nachrichtenraten pro Identität begrenzen.

Entscheidungskriterien und Hinweise

• Handshake-Authentifizierung ersetzt keine Autorisierung einzelner Aktionen.
• Lang laufende Verbindungen reagieren auf Sperrung und Token-Ablauf.

Zustand, Räume und zuverlässige Interaktion

Temporärer Verbindungszustand darf nicht mit dauerhaftem Fachzustand verwechselt werden. Präsenz ist flüchtig; fachliche Nachrichten benötigen persistente Speicher oder rekonstruierbare Ereignisprotokolle.

1. Räume nach fachlicher Ressource und Mandant benennen und serverseitig prüfen.
2. Präsenzmodell mit Verbindungs-ID, Nutzer-ID und Ablaufzeit definieren.
3. Mehrfachverbindungen desselben Nutzers bewusst behandeln.
4. Heartbeats, Leerlaufzeit und Server-Shutdown für sauberen Abbau konfigurieren.
5. Bestätigungen, Sequenznummern oder Revisionsstände für kritische Updates verwenden.
6. Reconnect mit Zustandssnapshot und anschließenden Deltas gestalten.
7. Verpasste Ereignisse über Historie oder fachliche Neusynchronisierung behandeln.

Entscheidungskriterien und Hinweise

• Präsenzdaten sind flüchtig und nicht die alleinige fachliche Wahrheit.
• Reconnect besitzt einen klaren Weg zur Zustandsrekonstruktion.

Skalierung, Backpressure und Betrieb

Bei mehreren Instanzen liegen Clients desselben Raums auf unterschiedlichen Prozessen. Ein gemeinsamer Adapter oder Broker verteilt Ereignisse; Lastgrenzen bleiben Aufgabe der Anwendung.

1. Sticky Sessions nur bei technischer Notwendigkeit und mit dokumentierten Folgen einsetzen.
2. Gemeinsamen Adapter oder Broker für Broadcasts und Raumzustand konfigurieren.
3. Langsame Clients, Sendepuffer und maximale Payload-Größe begrenzen.
4. Nachrichten priorisieren, zusammenfassen oder verwerfen, wenn Aktualisierungen überholt sind.
5. Metriken für Verbindungen, Raumgrößen, Raten, Fehler und Disconnects erfassen.
6. Kontrolliertes Herunterfahren mit Verbindungsdrain und Reconnect-Hinweis implementieren.
7. Mehrinstanz-, Broker- und Netzunterbrechungen testen.

Entscheidungskriterien und Hinweise

• Horizontale Skalierung wird mit realen Mehrinstanztests nachgewiesen.
• Backpressure verhindert unkontrolliertes Speicher- und Event-Loop-Wachstum.

Automatisierte Tests für Echtzeitabläufe

Tests verwenden reale Client-Verbindungen für Protokoll- und Lebenszyklusfragen. Fachlogik und Policies bleiben zusätzlich als schnelle Unit-Tests abgesichert.

1. Gateway mit Testanwendung auf zufälligem Port starten.
2. Client mit gültiger und ungültiger Identität verbinden.
3. Raumbeitritt, Broadcast, Bestätigung und Fehlerantwort prüfen.
4. Token-Ablauf, Sperrung und erzwungenen Disconnect simulieren.
5. Reconnect und Zustandsneusynchronisierung testen.
6. Langsamen Client und Nachrichtenburst zur Backpressure-Prüfung erzeugen.
7. Zwei Anwendungsinstanzen mit gemeinsamem Adapter verbinden.

Entscheidungskriterien und Hinweise

• Tests schließen Verbindungen und offene Handles kontrolliert.
• Zeitabhängige Abläufe verwenden feste Grenzen und nachvollziehbare Ereignisse.

Praxisprojekt: Live-Dashboard mit Benachrichtigungen

Ein Live-Dashboard zeigt mandantenbezogene Auftragszustände und erlaubt bestätigte Statusaktionen. Nutzer treten nur berechtigten Räumen bei; Änderungen werden als versionierte Ereignisse verteilt.

Das Labor umfasst Mehrfachverbindungen, Reconnect, Token-Ablauf, langsame Clients und zwei Serverinstanzen. Ein Snapshot-Endpunkt stellt den Zustand nach einer Unterbrechung wieder her.

1. Ereignisvertrag, Räume, Berechtigungen und Zustandsquelle definieren.
2. Gateway, Validierung und Application-Service-Anbindung implementieren.
3. Handshake-Authentifizierung und Policy-Prüfung für Raum sowie Aktion ergänzen.
4. Bestätigungen, Sequenzstände und Reconnect-Snapshot umsetzen.
5. Gemeinsamen Adapter für zwei Instanzen konfigurieren.
6. Rate Limits, Payload-Grenzen und Backpressure-Verhalten einrichten.
7. Client-, Sicherheits-, Reconnect- und Mehrinstanztests ausführen.
8. Verbindungs-, Nachrichten- und Fehlertelemetrie prüfen.

Prüfpunkte und typische Fehler

• Gateway enthält keine umfangreiche Fachlogik.
• Berechtigungen werden pro Raum und Aktion geprüft.
• Flüchtige Präsenzdaten sind nicht die alleinige fachliche Wahrheit.
• Reconnect besitzt einen definierten Weg zur Zustandsneusynchronisierung.
• Langsame Clients und Nachrichtenbursts belasten das System nicht unkontrolliert.
• Horizontale Skalierung wird mit Mehrinstanz- und Adaptertests nachgewiesen.