Alles bisher laeuft im Browser des Benutzers. Wenn jemand seine E-Mail abschickt, geht sie nirgendwohin -- wir zeigen nur eine gefaelschte Erfolgsmeldung. In dieser Lektion fuegen wir ein Backend hinzu, damit Daten tatsaechlich gespeichert werden.
Das grosse Bild
Konzept
Jede Webanwendung hat denselben grundlegenden Ablauf:Browser des Benutzers (Frontend) → API Route (Backend) → Datenbank → Antwort zurueck an den Browser
Das Frontend sammelt Benutzereingaben. Das Backend verarbeitet sie. Die Datenbank speichert sie. Die Antwort bestaetigt es. So funktioniert jede App der Welt -- von Google bis zu einem einfachen Anmeldeformular.
Next.js API Routes
Hier ist das Schoene an Next.js: Es handhabt auch Backend-Logik. Du brauchst keinen separaten Server. API Routes sind spezielle Dateien in deinem app/api/-Ordner, die serverseitige Logik verarbeiten.
Eine API Route ist einfach eine URL auf deinem Server, die Daten empfaengt und eine Antwort zurueckgibt. Zum Beispiel: POST /api/signup -- empfaengt eine E-Mail, speichert sie, gibt "Erfolg" zurueck.
Probier es aus
Tippe in Claude Code:"Create an API route at app/api/signup/route.ts that: - Accepts POST requests with a JSON body containing an email field - Validates the email format on the server side - Checks for duplicate emails - Stores the email with a timestamp in a local JSON file at data/signups.json - Returns a JSON response with success: true or an error message - Create the data directory if it doesn't exist"
Claude erstellt die API-Route-Datei. Das ist dein erster Backend-Code!
Einfach anfangen: JSON-Dateispeicher
Zu Lernzwecken speichern wir Daten in einer lokalen JSON-Datei. Das ist die einfachste moegliche "Datenbank" -- eine Datei, die eine Liste von E-Mails enthaelt. Sie funktioniert perfekt fuer die Entwicklung.
Nachdem Claude die API Route erstellt hat, sieht deine data/signups.json-Datei etwa so aus:
[
{ "email": "user@example.com", "timestamp": "2026-04-11T10:30:00Z" }
]
Ehrlicher Hinweis
Eine JSON-Datei ist keine echte Datenbank. Sie funktioniert gut zum Lernen und fuer kleine Tests, aber sie hat echte Einschraenkungen: keine Handhabung gleichzeitiger Zugriffe, keine Abfragemoeglichkeiten, kein Backup, und sie lebt auf einer einzelnen Maschine. In Lektion 10 wechseln wir zu DynamoDB -- einer echten Cloud-Datenbank. Aber fuer jetzt ist das das perfekte Lernwerkzeug.Frontend mit Backend verbinden
Jetzt aktualisieren wir das Anmeldeformular, damit es tatsaechlich Daten per POST an unsere neue API Route sendet:
Probier es aus
In Claude Code:"Update the signup form component to POST to /api/signup instead of simulating a delay. Send the email as JSON in the request body. Handle the response: - If the API returns success: true, show the success message - If the API returns an error (like duplicate email), show the error message from the API - Handle network errors with a generic 'Something went wrong. Please try again.' message"
Testen
- Stelle sicher, dass dein Dev-Server laeuft (
npm run dev) - Gehe zu http://localhost:3000
- Gib eine E-Mail ein und schicke das Formular ab
- Pruefe
data/signups.json-- deine E-Mail sollte dort sein! - Versuche, dieselbe E-Mail nochmal abzuschicken -- du solltest einen "Duplikat"-Fehler sehen
Probier es aus
Schicke ein paar verschiedene E-Mails ueber das Formular ab. Oeffne danndata/signups.json in VS Code, um zu ueberpruefen, ob alle da sind. Du hast gerade ein Full-Stack-Feature gebaut!
Datenvalidierung auf dem Server
Client-seitige Validierung (im Browser) ist nett fuer die Benutzererfahrung, aber sie reicht nicht aus. Jeder kann sie umgehen, indem er Anfragen direkt an deine API sendet.
Konzept
Vertraue niemals Daten vom Client. Validiere immer auch auf dem Server. Client-seitige Validierung dient der Benutzererfahrung (hilfreiche Fehler anzeigen). Server-seitige Validierung dient der Sicherheit (schlechte Daten ablehnen, egal wie sie gesendet wurden).Unsere API Route validiert E-Mails bereits auf dem Server -- Claude hat das eingebaut. Aber lass es uns robuster machen:
Add rate limiting to the signup API — maximum 5 signups per IP address
per hour. If exceeded, return a 429 status with a friendly message.
Deine API testen
Neben der Nutzung des Formulars im Browser kannst du deine API auch direkt testen:
Ueber den Network-Tab des Browsers:
- Oeffne die Developer Tools (F12)
- Gehe zum Network-Tab
- Schicke das Formular ab
- Klicke auf die
signup-Anfrage, um die Request- und Response-Details zu sehen
Mit curl in deinem Terminal (optional):
curl -X POST http://localhost:3000/api/signup \
-H "Content-Type: application/json" \
-d '{"email": "test@example.com"}'
Sicherheitshinweis
Ehrlicher Hinweis
Das ist ein Lernprojekt, und das ist in Ordnung. Aber eine Produktionsanwendung braucht mehr:- Authentifizierung -- ueberpruefen, wer Anfragen stellt - Rate Limiting -- Missbrauch verhindern (wir haben oben ein einfaches Limiting hinzugefuegt) - Input-Sanitisierung -- Injection-Angriffe verhindern - HTTPS -- Daten waehrend der Uebertragung verschluesseln - Umgebungsvariablen -- Geheimnisse aus dem Code heraushalten
Claude kann dir helfen, all das hinzuzufuegen, aber es ist wichtig zu wissen, dass es existiert. Sicherheit ist in echten Anwendungen nicht optional.
Git Checkpoint
git add .
git commit -m "backend API route with email storage and server-side validation"
Stelle sicher, dass du data/signups.json zu deiner .gitignore-Datei hinzufuegst -- du willst keine Benutzerdaten committen:
echo "data/signups.json" >> .gitignore
git add .gitignore
git commit -m "ignore signup data file"
Wichtigste Erkenntnis
Du hast gerade ein Full-Stack-Feature gebaut. Daten fliessen vom Browser des Benutzers ueber deine API Route in eine Datenbank (vorerst eine JSON-Datei). Das ist dasselbe Muster, das jede Anwendung der Welt nutzt -- und du hast es mit KI-Unterstuetzung gemacht.