Seminar Kuzzle Intensiv – Core, APIs und Anwendungsentwicklung

Der Intensivpfad bündelt Architektur, Administration, API- und SDK-Integration, Datenmodellierung, Realtime, Erweiterungsframework und Qualitätssicherung in einem zusammenhängenden Projekt. Alle Bausteine werden an einer durchgängigen Backend-Anwendung entwickelt, integriert und getestet. 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
• Tag 1: Architektur, Umgebung und Administration
• Tag 2: API-, SDK- und Datenintegration
• Tag 3: Realtime und ereignisorientierte Abläufe
• Tag 4: Controller, Plugins, Hooks und Pipes
• Tag 5: Qualitätssicherung, Pipeline und Abnahme
• Praxisprojekt und Lernerfolgskontrolle

Zielgruppe und Voraussetzungen

Kapitelinhaltsverzeichnis

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

Zielgruppe: Entwicklungsteams, Softwarearchitektur, technische Leads, Integrationsverantwortung und DevOps-nahe Entwicklung.

Voraussetzungen: Sichere Programmierkenntnisse, HTTP, JSON, Git und automatisierte Tests; Grundkenntnisse zu dokumentorientierter Datenhaltung.

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: Fünf Tage sind die notwendige Obergrenze, um die sieben zugeordneten Einzelthemen in einem verdichteten, aber noch praktisch belastbaren Lernpfad abzudecken. Jeder Tag bildet einen abgeschlossenen Projektinkrement; zusätzliche Vertiefungen werden bewusst in die spezialisierten Einzelseminare ausgelagert.

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. Tag 1: Architektur, Umgebung und Administration

Kapitelinhaltsverzeichnis

• Zielarchitektur
• Laboraufbau
• Admin Console und Kourou
• Erste Rollen und Daten

Dieses Kapitel verbindet Zielarchitektur, Laboraufbau, Admin Console und Kourou und Erste Rollen und Daten. 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 – Einen fachlichen Backend-Anwendungsfall mit Daten, Akteuren und Realtime-Bedarf schneiden: 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 – Die Laborumgebung starten und alle Abhängigkeiten mit einer Baseline 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 – Administrative Verbindungen und einen abgesicherten ersten Zugang einrichten: 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 – Indizes, Collections und ein minimales Rollenmodell anlegen: 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 – Den kompletten Ausgangszustand mit Kourou reproduzierbar dokumentieren: 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 Zielarchitektur ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Laboraufbau erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Erste Rollen und Daten lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Das Kursprojekt erhält eine lauffähige Plattformbasis mit Datenstruktur und getrennten Entwicklungs- sowie Administrationsrechten. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

2. Tag 2: API-, SDK- und Datenintegration

Kapitelinhaltsverzeichnis

• Client-Architektur
• Authentifizierung
• Repository und Suche
• Fehlerverträge

Dieses Kapitel verbindet Client-Architektur, Authentifizierung, Repository und Suche und Fehlerverträge. 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 – Eine zentrale SDK-Clientschicht mit Konfiguration und Request-Korrelation implementieren: 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 – Login, Token-Erneuerung und Abmeldung als nachvollziehbaren Zustandsautomaten umsetzen: 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 – Ein Repository für CRUD, Suche, Sortierung und Pagination erstellen: 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 – Mapping- und Validierungsfehler in stabile Anwendungsfehler übersetzen: 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 – Vertrags- und Negativtests für Daten- sowie Berechtigungszugriffe ausführen: 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 Client-Architektur ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Authentifizierung erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Fehlerverträge lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Das Kursprojekt kann authentifiziert Daten schreiben, suchen und robust auf typische API-Fehler reagieren. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

3. Tag 3: Realtime und ereignisorientierte Abläufe

Kapitelinhaltsverzeichnis

• Subscriptions und Filter
• Clientzustand
• Reconnect
• Fachereignisse

Dieses Kapitel verbindet Subscriptions und Filter, Clientzustand, Reconnect und Fachereignisse. 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 – Realtime-Anforderungen in präzise Filter und Empfängergruppen überführen: 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 – Subscriptions aufbauen und eingehende Notifications nach Kanal sowie Typ verarbeiten: 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 – Clientzustand für Eintritt, Änderung und Austritt eines Dokuments konsistent halten: 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 – Verbindungsabbruch, erneute Authentifizierung und Wiederanmeldung kontrolliert behandeln: 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 – Ein fachliches Ereignis mit Idempotenz und Beobachtbarkeit in den Ablauf integrieren: 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 Subscriptions und Filter ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Clientzustand erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Fachereignisse lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Eine Live-Ansicht wird mit gefilterten Notifications, Reconnect und Konsistenzprüfung umgesetzt. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

4. Tag 4: Controller, Plugins, Hooks und Pipes

Kapitelinhaltsverzeichnis

• Custom Controller
• Service- und Domänenlogik
• Hooks und Pipes
• Konfiguration und Fehler

Dieses Kapitel verbindet Custom Controller, Service- und Domänenlogik, Hooks und Pipes und Konfiguration und Fehler. 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 – Eine projektspezifische API-Grenze mit Controller und eindeutigem Requestvertrag entwerfen: 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 – Fachlogik in testbare Services auslagern und Kontextzugriffe kapseln: 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 – Pipes für synchrone Prüfung und Hooks für asynchrone Reaktion gezielt einsetzen: 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 – Konfiguration und Secrets außerhalb des Codes verwalten: 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 – Fehlerkennungen, Logging und Berechtigungen der Erweiterung vereinheitlichen: 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 Custom Controller ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Service- und Domänenlogik erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Konfiguration und Fehler lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Das Kursprojekt erhält eine eigene API-Funktion mit Validierung, Ereignisverarbeitung und sauberer Fehlerbehandlung. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

5. Tag 5: Qualitätssicherung, Pipeline und Abnahme

Kapitelinhaltsverzeichnis

• Testpyramide
• Integrationstests
• CI/CD-Gates
• Release- und Betriebsübergabe

Dieses Kapitel verbindet Testpyramide, Integrationstests, CI/CD-Gates und Release- und Betriebsübergabe. 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 – Risiken in Unit-, Integrations-, Vertrags-, Security- und Realtime-Tests übersetzen: 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 – Eine isolierte Testumgebung mit deterministischen Daten automatisiert bereitstellen: 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 – Fehler-, Last- und Wiederverbindungsszenarien in die Testsuite aufnehmen: 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 – Build, Prüfung, Paketierung und kontrolliertes Deployment als Pipeline definieren: 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 – Das Gesamtprojekt anhand von Abnahmekriterien demonstrieren und technische Schulden erfassen: 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 Testpyramide ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Integrationstests erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Release- und Betriebsübergabe lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Das vollständige Backend wird automatisiert geprüft, als Releasekandidat gebaut und mit einer technischen Abnahme übergeben. 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.