Aufgabe 16 - Client trifft Server

Aufgabe 16 - Client trifft Server

Worum geht es?

Die Buffet-API bekommt ein Gesicht: die Weboberfläche, die über Ihre eigene Schnittstelle liest und schreibt, mit sauberem Umgang mit Laden, Fehlern und Erfolg. Client und Server leben im selben Projekt, und alles aus den React- und Async-Wochen kommt hier zusammen (siehe Kapitel Next.js II).

Was Sie dafür brauchen

• Kapitel Next.js II; Ihre API aus Aufgabe 15 im selben Projekt.

Welche Kompetenzen Sie erwerben und zeigen

• Sie wählen begründet zwischen Datenbeschaffung in Server-Komponenten und fetch im Client.
• Sie bauen Formulare mit Validierung, In-Flight-Schutz und Fehleranzeige aus dem Vertragsformat.
• Sie machen asynchrone Zustände (Laden, Fehler, Erfolg) in der Oberfläche sichtbar.

Pädagogische Einordnung

• Reproduktion: die Anzeige-Seite nach dem Kapitelmuster aufbauen (Teil A).
• Reorganisation und Transfer: Mutationen, Rollen-Sichten und Aktualisierung kombinieren (Teile B und C).
• Reflexion, Problemlösung und Urteilsbildung: das Verhalten bei Störungen untersuchen und robust gestalten (Teil D).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt. Teil D ist der Expertenteil.

Teil A - Die Schülersicht: lesen

1. /buffet zeigt das Tagesangebot. Entscheiden Sie: Liest die Server-Komponente direkt über das gemeinsame Logik-Modul oder per fetch über die eigene API? Begründen Sie die Wahl in zwei Sätzen (das Kapitel nennt die Kriterien).
2. Ausverkaufte Artikel werden angezeigt, aber sichtbar deaktiviert (abgeleitet aus der Menge, kein eigener State).

Teil B - Die Schülersicht: bestellen

1. Bestellformular als Client-Komponente: Positionen zusammenklicken (höchstens 5, nur verfügbare Mengen); der Absenden-Button ist deaktiviert, solange die Bestellung ungültig ist.
2. Der Client kennt die Grenzen, aber der Server prüft nochmals; beantworten Sie im Kommentar, warum doppelt geprüft wird und welche der beiden Prüfungen verzichtbar wäre.
3. Absenden per fetch an POST /api/orders mit dem kompletten Muster des Kapitels: In-Flight-Flag gegen Doppelklick, Ladezustand am Button, Fehlermeldung aus dem Vertrags-Fehlerformat (error.message), bei Erfolg Abholnummer groß anzeigen und Formular zurücksetzen.

Teil C - Die Buffetsicht

1. /buffet/admin: Bestellliste mit Status und Buttons “fertig” und “abgeholt” (PATCH); nach jeder Aktion aktualisiert sich die Liste (router.refresh() oder State-Update, eine der beiden Varianten begründet gewählt).
2. Fehlerfälle sichtbar: Liefert die API 409 (ungültiger Statuswechsel, etwa nach Doppelklick auf “fertig”), erscheint eine Inline-Meldung an der betroffenen Bestellung; kein alert, kein stiller Fehlschlag.
3. Die Rollensimulation (x-role-Header) wird beim fetch mitgeschickt; kapseln Sie das in einer kleinen Client-Hilfsfunktion, damit sie in Aufgabe 20 an genau einer Stelle ersetzt werden kann.

Teil D - Expertenteil: Der Störungstest

1. Stoppen Sie den Dev-Server, während die Buffet-Seite offen ist, und lösen Sie eine Bestellung aus. Protokollieren Sie das Verhalten ohne Ihre Schutzmaßnahmen (welche Meldung, welcher Zustand bleibt zurück?).
2. Härten Sie: Der Netzwerkfehler (fetch wirft) wird gefangen und als verständliche Meldung mit Retry-Button angezeigt; nach Serverneustart führt Retry die Bestellung ohne Neuladen der Seite aus. Kein Formularinhalt geht verloren.
3. Prüfen Sie die heikle Frage der Doppelbestellung: Wenn der Server die Bestellung angenommen hat, aber die Antwort den Client nie erreichte, was passiert bei Retry? Dokumentieren Sie das Verhalten Ihrer API und schlagen Sie in zwei Sätzen eine Verbesserung vor (Stichwort: Idempotenz, etwa über eine vom Client vergebene Bestellkennung).
4. Führen Sie den kompletten Bestellablauf inklusive Störungstest als Screenshot-Serie oder kurzes Video vor.

Wissenscheck

1. Nach welchen Kriterien entscheidet man zwischen Server-Komponenten-Datenzugriff und Client-fetch?
2. Warum ersetzt die Client-Validierung die Server-Validierung nicht?
3. Welche drei Zustände jeder Mutation muss die Oberfläche sichtbar machen?
4. Was bewirkt router.refresh() nach einer erfolgreichen Mutation?
5. Warum ist ein wiederholtes POST heikel, ein wiederholtes PATCH auf denselben Zielstatus aber nicht?

Abgabe

Git-Repository (API und Frontend), die Screenshot-Serie oder das Video des Bestellablaufs inklusive Störungstest und das Störungsprotokoll aus Teil D.