Aufgabe 22 - Projekt Client-Server-Anwendung

Aufgabe 22 - Projekt: Client-Server-Anwendung

Worum geht es?

Das Jahresprojekt: In Teams von zwei bis drei Personen entwickeln Sie eine umfangreiche Client-Server-Anwendung mit allem, was dieses Jahr erarbeitet wurde: eigene dokumentierte REST-Schnittstelle, Mehrschichtarchitektur, Persistenz, sichtbare Nebenläufigkeit, Validierung und der verbindliche Team-Workflow mit Reviews (alle Kapitel des Jahres). Diese Aufgabe startet das Projekt und definiert seinen Rahmen; die vier Projektwochen laufen nach den Meilensteinen unten.

Was Sie dafür brauchen

• Alle Kapitel des Schuljahres; die Aufgaben 10 und 15 bis 21 als handwerkliche Vorlagen.
• Ein Team-Repository am Schul-GitLab mit geschütztem main, Board und CI-Pipeline (Kapitel Qualität im Team).

Welche Kompetenzen Sie erwerben und zeigen

• Sie planen und bauen ein Client-Server-System im Team, vom API-Vertrag bis zur Präsentation.
• Sie integrieren Architektur, Persistenz, Nebenläufigkeit und Validierung zu einem lauffähigen Ganzen.
• Sie arbeiten nachweisbar im professionellen Workflow (Branches, MRs, Reviews, Pipeline).

Pädagogische Einordnung

• Reproduktion: die eingeübten Bausteine (API, Schichten, Formulare) im neuen Kontext wiederverwenden (Wochen 1 und 2).
• Reorganisation und Transfer: die Bausteine zu einem eigenen System kombinieren und an das gewählte Thema anpassen (Wochen 2 und 3).
• Reflexion, Problemlösung und Urteilsbildung: Architektur- und Teamentscheidungen treffen, verteidigen und im Abschlussbericht reflektieren (laufend und Woche 4).

Rahmen

• Dauer: 4 Wochen laut Wochenplan; Teams von 2 bis 3 Personen.
• Thema: frei wählbar mit Medientechnik-Bezug (Abstimmung mit den fachtheoretischen Gegenständen), etwa Medienarchiv mit Upload und Tagging, Event-Anmeldung mit Ticket-Code, kollaboratives Moodboard, Turnierverwaltung mit Live-Stand. Genehmigung durch die Lehrkraft in Woche 1.

Arbeitsaufträge

Teil A - Woche 1: Fundament (Meilenstein 1)

1. Thema festlegen und genehmigen lassen; Projektorganisation schriftlich: Rollen, Board mit ersten Issues, Definition of Done (Kapitel Qualität im Team).
2. API zuerst: das vollständige API-Dokument im Stil von Aufgabe 10 (Ressourcen, Endpunkte, Formate mit Beispielen, Statuscodes, Fehlerformat), im Team reviewt.
3. Schichten- und Datenmodell-Diagramm; Repository mit Projektgerüst, CI-Pipeline und geschütztem main.

Teil B - Woche 2: Die Schnittstelle steht (Meilenstein 2)

1. API implementiert nach Vertrag: Route Handler als dünne Adapter, Geschäftsregeln im Service, SQLite-Repository hinter dem Interface.
2. Validierung mit zod an jeder Grenze; Zugriffskontrolle über Middleware, wo das Thema Rollen braucht.
3. Abnahmeskript oder API-Tests decken Lebenszyklus und Fehlerfälle ab; die Pipeline führt sie aus. Frontend-Gerüst (Layout, Navigation, erste Lesesicht) steht.

Teil C - Woche 3: Feature-vollständig (Meilenstein 3)

1. Alle geplanten Funktionen über die Oberfläche bedienbar; Mutationen mit In-Flight-Schutz, Fehleranzeige aus dem Vertragsformat, Aktualisierung der Ansichten.
2. Nebenläufigkeit sichtbar: mindestens eine Stelle mit koordinierten parallelen Abläufen (parallele Abrufe mit Sammelbericht, Live-Aktualisierung per Polling, Schutz gegen überholte Antworten), im Abschlussbericht benannt und erklärt.
3. Code-Freeze am Wochenende: danach nur noch Bugfixes.

Teil D - Woche 4: Feinschliff und Nachweis (Meilenstein 4)

1. Kür (mindestens eine): Datenaustausch mit dem Projekt eines anderen Teams (Export/Import mit Konverter), einfache Echtzeit-Funktion (Polling oder Server-Sent Events), Datei-Upload mit Verarbeitung (etwa Bildgrößen).
2. Abschlussbericht (2 bis 4 Seiten): Architektur am Diagramm, die Nebenläufigkeits-Stelle, die schwierigste Entscheidung mit Begründung, ehrliche Grenzen des Systems.
3. Präsentation (10 Minuten): Live-Demo des Kernablaufs inklusive eines provozierten Fehlerfalls, Architektur-Erklärung, Fragen. Jedes Teammitglied präsentiert einen Teil.
4. Demo-Härtung: Kein unbehandelter 500er im Demo-Durchlauf; der Angriffstest aus Aufgabe 20 wird einmal aufs eigene Projekt wiederholt.

Wissenscheck (zur Projekthalbzeit im Team zu beantworten)

1. Stimmt unsere Implementierung noch mit dem API-Dokument überein, und wo ist der Changelog?
2. Welche Geschäftsregel steht wo, und gibt es sie garantiert nur einmal?
3. Läuft unsere Pipeline bei jedem Push, und blockiert sie rote Merges?
4. Wo ist unsere Nebenläufigkeits-Stelle, und wie weisen wir ihr korrektes Verhalten nach?
5. Kann jedes Teammitglied jede Schicht erklären, auch die selbst nicht gebauten?

Beurteilung

Funktionalität (30 %), Architektur und Codequalität (25 %), API-Design und Doku (15 %), Tests (10 %), Teamworkflow und Reviews (10 %), Präsentation (10 %). Individuelle Beiträge sind über die Git-Historie nachvollziehbar; “ein Commit pro Person” fällt auf.

Abgabe

Repository-Link (Historie mit Branches, MRs und Reviews), API-Dokument mit Changelog, Diagramme, Abschlussbericht; Präsentation im Unterricht der vierten Woche.