Aufgabe 19 - BFF-Proxy in Next.js bauen

Aufgabe 19 - BFF-Proxy in Next.js bauen

Worum geht es?

Sie bauen den dritten Weg aus dem Kapitel: Der Browser spricht nur noch mit seiner eigenen Origin, und der Server dahinter holt die Daten (siehe Kapitel Getrennte Systeme). Damit verschwindet CORS vollständig, und das Zugriffstoken bleibt auf dem Server. Sie bauen dieselbe Sache anschließend noch einmal ohne eine Zeile Code, nämlich als Pfadregel im Reverse Proxy, und vergleichen beides.

Was Sie dafür brauchen

• Kapitel Getrennte Systeme, Abschnitt Das BFF-Muster.
• Die beiden Anwendungen aus Aufgabe 18, das Frontend als Next.js-Projekt.
• Für Teil C den Traefik aus Kapitel 3 oder eine lokale Reverse-Proxy-Konfiguration.

Welche Kompetenzen Sie erwerben und zeigen

• Sie bauen einen Route Handler, der Anfragen an eine API weiterleitet und dabei ein Token ergänzt.
• Sie erklären, warum in Server Components ein Teil der CORS-Fragen gar nicht erst auftaucht.
• Sie entscheiden begründet zwischen BFF, Proxy-Pfad und direkten Aufrufen.

Pädagogische Einordnung

• Reproduktion: einen Route Handler anlegen und eine Anfrage weiterleiten (Teil A).
• Reorganisation und Transfer: Token serverseitig ergänzen und Aufrufe bündeln (Teil B).
• Reflexion, Problemlösung und Urteilsbildung: die drei Bauformen vergleichen und auswählen (Teil C).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt.

Teil A - Der erste Route Handler

1. Legen Sie in Ihrem Next.js-Frontend einen Route Handler unter /api/ping an, der eine feste Antwort zurückgibt. Rufen Sie ihn im Browser auf und notieren Sie die Adresse.

2. Beantworten Sie in zwei Sätzen, warum dieser Aufruf keinen CORS-Fehler auslöst, obwohl Sie in Aufgabe 17 bei jedem Aufruf einen bekommen haben.

3. Erweitern Sie den Handler so, dass er die Anfrage an Ihre API auf dem anderen Port weiterleitet und deren Antwort zurückgibt. Notieren Sie die Adresse der API als Umgebungsvariable, nicht fest im Code.

4. Rufen Sie den Handler aus dem Browser auf. Sehen Sie im Netzwerk-Tab nach, welche Adressen der Browser tatsächlich anfragt, und notieren Sie sie.

5. Prüfen Sie, ob in Ihrer API noch CORS-Kopfzeilen nötig sind. Schalten Sie sie testweise ab und rufen Sie erneut über den Handler auf. Beschreiben Sie das Ergebnis in zwei bis drei Sätzen.

Teil B - Token und Bündelung

1. Legen Sie in Ihrer API ein Zugriffstoken fest, das für jeden Aufruf verlangt wird. Endpunkte ohne gültiges Token antworten mit 401.

2. Hinterlegen Sie das Token als Umgebungsvariable im Frontend-Server und lassen Sie den Route Handler es bei der Weiterleitung im Authorization-Header ergänzen.

3. Weisen Sie nach, dass das Token nicht im Browser landet. Suchen Sie im Netzwerk-Tab, im Quelltext der Seite und im ausgelieferten JavaScript danach. Notieren Sie zu jedem der drei Orte das Ergebnis.

4. Beschreiben Sie in drei bis vier Sätzen, welche Diskussion aus Aufgabe 18 damit hinfällig wird.

5. Bauen Sie einen zweiten Route Handler, der zwei API-Aufrufe zu einer Antwort bündelt, etwa eine Liste und die zugehörigen Stammdaten. Messen Sie die Zeit einmal mit zwei getrennten Aufrufen aus dem Browser und einmal mit dem gebündelten Aufruf. Notieren Sie beide Zeiten.

6. Erklären Sie in zwei bis drei Sätzen, warum dieser Unterschied auf einer Mobilverbindung deutlicher ausfällt als in Ihrem Schulnetz.

7. Bauen Sie dieselbe Datenabfrage einmal als Server Component. Prüfen Sie im Netzwerk-Tab, welche Anfragen der Browser dabei stellt, und beschreiben Sie in drei bis vier Sätzen, warum die Same-Origin-Policy hier keine Rolle spielt.

Teil C - Die dritte Bauform und die Entscheidung

1. Richten Sie dieselbe Wirkung ohne eigenen Code ein: eine Pfadregel im Reverse Proxy, die /api/* an den API-Container leitet und alles andere ans Frontend. Notieren Sie die Konfigurationszeilen.

2. Prüfen Sie mit curl -i, dass beide Pfade unter derselben Adresse antworten, und notieren Sie die Ausgabe.

3. Stellen Sie die drei Bauformen in einer Tabelle gegenüber, mit den Zeilen CORS nötig, Token im Browser, Aufrufe bündelbar, zusätzlicher Netzwerkweg, Aufwand, kann ausfallen. Die Spalten sind direkter Aufruf, BFF-Route-Handler und Proxy-Pfad.

4. Beschreiben Sie in vier bis fünf Sätzen den Unterschied zwischen dem echten BFF und der Proxy-Variante. Gehen Sie darauf ein, was der Proxy ausdrücklich nicht kann.

5. Der Frontend-Server wird beim BFF zu einem Bauteil, das ausfallen kann. Beschreiben Sie in drei bis vier Sätzen, was ein Benutzer sieht, wenn die API läuft und der Frontend-Server nicht, und vergleichen Sie das mit dem umgekehrten Fall.

6. Entscheiden Sie sich für eine der drei Bauformen für Ihr eigenes Projekt und schreiben Sie den Eintrag in docs/entscheidungen.md mit Entscheidung, Alternativen, Begründung und Folgen. Für ein Schulprojekt ist die Proxy-Variante oft die passende Wahl, und diese Begründung müssen Sie mit Ihren eigenen Zahlen aus Teil B stützen oder widerlegen.

7. Aktualisieren Sie Ihre Origin-Tabelle in docs/architektur.md nach der getroffenen Entscheidung. Wenn CORS entfällt, gehört das dort ausdrücklich vermerkt.

Wissenscheck

1. Warum entfällt CORS beim BFF-Muster vollständig?
2. Wo liegt beim BFF das Zugriffstoken für die API, und warum ist das ein Gewinn?
3. Welche zwei Bauformen des BFF bietet Next.js?
4. Warum spielt die Same-Origin-Policy in einer Server Component keine Rolle?
5. Welchen Vorteil hat ein BFF gegenüber einem reinen Proxy-Pfad?
6. Welche drei Kosten bringt das BFF-Muster mit?
7. Warum ist die Proxy-Variante für ein Schulprojekt oft ausreichend?

Abgabe

Der Route Handler mit Weiterleitung und Token liegt als Code vor, ebenso der bündelnde Handler und die Server-Component-Variante. In protokoll.md stehen die drei Suchergebnisse nach dem Token, die beiden Zeitmessungen, die Konfigurationszeilen des Proxys und die Vergleichstabelle der drei Bauformen. Der Entscheidungseintrag steht in docs/entscheidungen.md, die aktualisierte Origin-Tabelle in docs/architektur.md.