Seminar Kuzzle Realtime-Anwendungen und Event-Architekturen

Das Seminar entwickelt belastbare Realtime-Funktionen mit Koncorde-Filtern, Subscriptions, Notifications und fachlichen Events. Clientzustand, Berechtigungen, Reconnect, Deduplizierung, Skalierung, Ereignisverträge und beobachtbare Fehlerpfade werden an einer Live-Anwendung umgesetzt. Theorie, Demonstration und Laborarbeit wechseln in kurzen Zyklen. Jeder technische Schritt wird durch eine Kontrollabfrage, einen Negativtest oder eine nachvollziehbare Zustandsprüfung abgeschlossen.

Inhaltsübersicht

• Zielgruppe und Voraussetzungen
• Didaktischer Zuschnitt
• Ereignisverträge und Subscription-Schnitt
• Subscriptions und Clientzustand
• Reconnect, Authentifizierung und Fehlerzustände
• Security, Skalierung und Teststrategie
• Praxisprojekt und Lernerfolgskontrolle

Zielgruppe und Voraussetzungen

Kapitelinhaltsverzeichnis

• Adressierte Rollen
• Erforderliche Vorkenntnisse
• Labor- und Arbeitsmittel
• Einstiegskontrolle

Zielgruppe: Frontend- und Backend-Entwicklung, Softwarearchitektur, IoT-Entwicklung und technische Qualitätssicherung.

Voraussetzungen: Sichere Kenntnisse in asynchroner Programmierung, JSON und Clientzustandsverwaltung; Kuzzle-API-Grundlagen.

Zu Beginn werden Vorkenntnisse, Laborzugang, Namenskonventionen und Sicherheitsregeln geprüft. Fehlende Grundlagen werden als konkrete Vorbereitungspunkte dokumentiert; produktive Systeme und reale Zugangsdaten werden in den Übungen nicht verwendet.

Didaktischer Zuschnitt

Kapitelinhaltsverzeichnis

• Begründung der Dauer
• Arbeitsweise
• Dokumentationsstandard
• Qualitätssicherung

Begründung der Dauer: Drei Tage sind erforderlich, weil Filter- und Subscriptionmodell, konsistente Clientverarbeitung sowie Resilienz, Security und Skalierung jeweils praktisch aufgebaut werden. Ein kürzeres Format würde den Reconnect- und Konsistenznachweis auf einfache Happy-Path-Demonstrationen beschränken.

Die Lerneinheiten folgen dem Muster Analyse, Aufbau, Funktionsnachweis, Fehlerfall und Wiederholung. Konfigurationen und Testdaten werden versionierbar gehalten. Entscheidungen werden mit Annahme, Alternative, Risiko und Prüfmethode dokumentiert. Dadurch entsteht neben dem fachlichen Verständnis ein direkt nutzbares Arbeitsverfahren.

1. Ereignisverträge und Subscription-Schnitt

Kapitelinhaltsverzeichnis

• Fachereignis und Dokumentänderung
• Filter und Scope
• Empfängergruppen
• Payload und Versionierung

Dieses Kapitel verbindet Fachereignis und Dokumentänderung, Filter und Scope, Empfängergruppen und Payload und Versionierung. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Reaktionsbedarf und zulässige Verzögerung für jedes Live-Szenario beschreiben: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Dokumentänderung, Publish-Nachricht und projektspezifisches Event bewusst unterscheiden: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Koncorde-Filter so eng wie möglich aus fachlichen Kriterien ableiten: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Scope, Benutzerereignisse und Volatile-Daten nur bei konkretem Bedarf aktivieren: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Notification-Payloads und fachliche Eventverträge versionieren: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Fachereignis und Dokumentänderung ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Filter und Scope erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Payload und Versionierung lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Für eine Live-Übersicht entsteht ein Satz minimaler, nachvollziehbarer Subscriptions mit Ereignisverträgen. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

2. Subscriptions und Clientzustand

Kapitelinhaltsverzeichnis

• Kanal und Room
• Initialsnapshot
• In-, Out- und Delete-Ereignisse
• Sortierung und Deduplizierung

Dieses Kapitel verbindet Kanal und Room, Initialsnapshot, In-, Out- und Delete-Ereignisse und Sortierung und Deduplizierung. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Zuerst einen konsistenten Initialsnapshot laden und dessen Zeitbezug festhalten: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Subscription eröffnen und Kanal sowie Room-ID im Clientzustand registrieren: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Eintretende, verbleibende und austretende Dokumente korrekt unterscheiden: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Updates anhand von Identität und Version deduplizieren: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Sortierung, Filter und Aggregatwerte nach jeder Notification deterministisch aktualisieren: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Kanal und Room ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Initialsnapshot erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Sortierung und Deduplizierung lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Eine Live-Liste bleibt bei Erstellen, Ändern, Löschen und Verlassen des Filters konsistent. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

3. Reconnect, Authentifizierung und Fehlerzustände

Kapitelinhaltsverzeichnis

• Verbindungszustand
• Tokenwechsel
• Wiederanmeldung
• Lücken und Resynchronisierung

Dieses Kapitel verbindet Verbindungszustand, Tokenwechsel, Wiederanmeldung und Lücken und Resynchronisierung. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Online-, verbindend-, offline-, wiederherstellend- und fehlerhaft-Zustände explizit modellieren: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Tokenablauf und Verbindungsabbruch als getrennte Ursachen behandeln: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Nach Reconnect Authentifizierung und Subscriptions in definierter Reihenfolge erneuern: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Mögliche Ereignislücken durch erneuten Snapshot oder Zeitmarken schließen: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Abbruchgrenzen, Benutzerhinweise und technische Telemetrie für Dauerausfälle festlegen: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Verbindungszustand ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Tokenwechsel erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Lücken und Resynchronisierung lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Die Anwendung übersteht Serverneustart, Tokenablauf und kurzzeitigen Netzverlust ohne doppelten oder veralteten Zustand. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

4. Security, Skalierung und Teststrategie

Kapitelinhaltsverzeichnis

• Filterberechtigungen
• Room- und Verbindungsgrenzen
• Lastprofil
• Deterministische Tests

Dieses Kapitel verbindet Filterberechtigungen, Room- und Verbindungsgrenzen, Lastprofil und Deterministische Tests. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Subscriptions mit denselben Rollen- und Datenrestriktionen wie synchrone Abfragen testen: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Fremde Daten über absichtlich breite Filter negativ prüfen: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Anzahl Verbindungen, Rooms, Filterkomplexität und Notification-Rate messen: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Lasttests mit realistischen Churn- und Reconnect-Mustern ausführen: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Ereignisfolgen deterministisch aufzeichnen und als Regressionstest wiedergeben: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Filterberechtigungen ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Room- und Verbindungsgrenzen erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Deterministische Tests lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Ein Last- und Security-Test weist nach, dass mehrere Rollen nur zulässige Live-Daten erhalten und die Zielrate verarbeitet wird. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

Praxisprojekt und Lernerfolgskontrolle

Kapitelinhaltsverzeichnis

• Projektauftrag
• Zwischenprüfungen
• Fehler- und Sicherheitsnachweis
• Technische Abnahme

Das Praxisprojekt verbindet die Kapitel zu einer konsistenten Laborlösung. Vor jedem Inkrement werden Ausgangszustand, Ziel, Eingaben und Abnahmekriterien festgelegt. Nach der Umsetzung folgen Funktionsprüfung, Negativtest, kurze Dokumentationskontrolle und Rücksetzung auf einen bekannten Zustand.

1. Projektauftrag schneiden: Ein fachlich begrenzter Anwendungsfall wird in Daten, Akteure, Schnittstellen, Berechtigungen und Betriebsanforderungen zerlegt.
2. Inkremente umsetzen: Die Kapitelbausteine werden schrittweise integriert; nach jedem Inkrement bleibt die Laborlösung lauffähig.
3. Fehler nachweisen: Mindestens ein Berechtigungs-, Daten-, Verbindungs- oder Konfigurationsfehler wird kontrolliert ausgelöst und diagnostiziert.
4. Abnahme durchführen: Eine technische Checkliste prüft Funktion, Sicherheit, Wiederholbarkeit, Protokollierung und Rückfallfähigkeit.
5. Lernstand dokumentieren: Offene Vertiefungen werden als priorisierte Aufgaben mit benötigtem Nachweis festgehalten.

Die Lernerfolgskontrolle besteht aus kurzen Verständnisfragen, beobachteten Laboraufgaben, einer Fehlersuche und der technischen Abnahme des Praxisprojekts. Bewertet werden nicht nur funktionierende Ergebnisse, sondern auch Begründung, Nachweis, sichere Fehlerbehandlung und Reproduzierbarkeit.