azena backend
Du verstehst, wie das Backend einer modernen App funktioniert — Datenmodell, API-Schicht, Datenbank und Auth — und baust mit Claude Code eine echte, sichere API, die ein Frontend zuverlässig bedient.
Was du danach kannst
- Die Schichten Client → API → Datenbank sauber trennen und erklären
- Ein einfaches, sinnvolles Datenmodell entwerfen (Tabellen, Relationen)
- REST/Serverless-Endpunkte bauen (CRUD, Status-Codes, Validierung)
- Eine Datenbank (Supabase) anbinden und Auth integrieren
- Mit Claude Code eine API bauen, testen und absichern
Das Curriculum
19 Lektionen · Schritt für Schritt
- 01
Die Schichten verstehen — Client, API, Datenbank
10′Warum eine App in Schichten denkt — und welche Verantwortung wo liegt.
- 02
Das Datenmodell — Tabellen, die Sinn ergeben
11′Gute Software fängt bei den Daten an. Ein klares Modell erspart dir tausend spätere Probleme.
- 03
REST-Endpunkte bauen — CRUD, Status, Validierung
11′Die immer gleichen vier Operationen — und wie eine saubere API antwortet.
- 04
Dein Backend für KI-Agenten öffnen — einen MCP-Server bauen
10′REST ist für Menschen-Clients. 2026 kommt ein zweiter Client-Typ dazu: der KI-Agent. Das Model Context Protocol (MCP) ist die standardisierte Art, ihm dein Backend zu öffnen.
- 05
Datenbank & Auth anbinden — mit Claude bauen
10′Supabase als Datenbank + Auth, sicher angebunden — und Claude als Co-Developer.
- 06
Authentifizierung im Detail — Sessions, JWT & OAuth2
12′Wie Login wirklich funktioniert — und wann Session-Cookie, wann Token, wann „Login mit …“.
- 07
Caching — schnell und frisch zugleich
11′Die billigste Performance kommt davon, Arbeit nicht zu wiederholen — wenn die Invalidierung stimmt.
- 08
Queues & Hintergrund-Jobs — nicht alles sofort
11′Langsames aus dem Request rausnehmen: E-Mails, Bilder, KI-Calls gehören in die Warteschlange.
- 09
Testen — Vertrauen statt Hoffnung
11′Schnell bauen UND nichts kaputt machen — die Test-Pyramide und was sie für KI-Code bedeutet.
- 10
Observability & Skalierung — wissen, was läuft
11′Logs, Metriken, Traces — und die wenigen Hebel, die eine App wirklich skalierbar machen.
- 11
Resilienz — wenn Abhängigkeiten ausfallen
11′Verteilte Systeme scheitern teilweise. Gute Backends rechnen damit, statt zu hoffen.
- 12
Fehlerbehandlung & Error-Responses — sauber scheitern
11′Eine API wird an ihren Fehlern gemessen — saubere Codes, klare Bodies, niemals ein Stacktrace nach außen.
- 13
Pagination, Filtering & Sorting — große Listen API-freundlich
11′„Gib mir alle“ ist eine Zeitbombe. Eine reife Liste-API liefert in Seiten, filtert und sortiert kontrolliert.
- 14
Rate-Limiting & API-Schutz — Missbrauch abwehren
11′Eine offene API ist eine Einladung. Rate-Limiting hält Überlast, Scraping und Brute-Force draußen.
- 15
Datenbank-Indizes & Query-Performance — warum es langsam ist
12′Fast jede „die App ist langsam“-Beschwerde endet bei einer Abfrage ohne Index. Hier lernst du, sie zu finden.
- 16
Datenbank-Transaktionen & Konsistenz — ACID gegen Race Conditions
12′Zwei Requests gleichzeitig, ein Konto: Ohne Transaktionen entstehen Geister-Buchungen. ACID und Locking halten die Daten korrekt.
- 17
Realtime & WebSockets — Live-Updates statt ständig nachfragen
11′Chat, Live-Status, Kollaboration: Wenn der Server von sich aus pushen muss, reicht klassisches Request/Response nicht mehr.
- 18
Datei-Uploads & Storage — große Dateien sicher annehmen
11′Ein Bild-Upload klingt trivial — bis jemand 4 GB, eine .exe als „.jpg“ oder 10.000 Dateien gleichzeitig schickt. So nimmt man Dateien richtig an.
- 19
API-Versionierung & Abwärtskompatibilität
10′Sobald andere deine API nutzen, darfst du sie nicht einfach brechen — Versionierung schafft Freiheit.
Was du baust
Echte Artefakte, keine Theorie
Ein Datenmodell entwerfen
Ergebnis: Das Datenmodell (Tabellen + Beziehungen, gern als SQL) + 2-3 Sätze, warum es so aufgebaut ist.
Einen CRUD-Endpunkt mit Validierung bauen
Ergebnis: Der funktionierende Endpunkt (Code) + ein kurzer Test/curl-Aufruf, der Erfolg UND einen Fehlerfall (z.B. 400) zeigt.
Datenbank + Auth verbinden
Ergebnis: Migration + Client-Setup + ein Nachweis, dass fremder Zugriff durch RLS blockiert wird.
Capstone: Sichere REST-API mit Auth, RLS, Tests & Caching
Ergebnis: Repo-Link + ein Test, der Erfolg UND einen Fehlerfall zeigt + Beleg, dass RLS fremden Zugriff blockt + Vorher/Nachher der indizierten Query.
Belege & Quellen
Jede Aussage ist belegt — echte, geprüfte Quellen statt Behauptungen.
Reinschnuppern
Gratis-VorschauGO vs. NO-GO — ein echtes Beispiel aus dem Track.
Wie der Track läuft
Mit Nova als Mentor
Dein KI-Mentor erklärt jedes Konzept, gibt dir fertige Claude-Code-Prompts und hilft bei jeder Frage.
Erwische den Fehler
Kein Erklären: Nova hat echten Code mit einer eingebauten Schwachstelle produziert — du reviewst ihn wie in einem Pull Request, findest den Fehler und nennst den Fix. Erst wenn du den echten Fehler erwischst, verdienst du dein Siegel.
In deinem Tempo
Rund 198 Minuten Kerninhalt — plus deine eigenen Projekte. Jederzeit pausierbar.
Fehler, die du vermeidest
- Regeln/Auth nur im Client — die API-Schicht fehlt oder prüft nicht.
- Daten dupliziert speichern statt über Fremdschlüssel zu verknüpfen.
- Immer 200 zurückgeben statt passender Status-Codes.
- Eingaben nicht serverseitig validieren (auf den Client vertrauen).
- Service-Role-Key in den Client/ins Repo bringen.
- Migrationen blind auf die Produktiv-DB anwenden, ohne die Diffs zu prüfen.
Bereit für azena backend?
250 Token · 19 Lektionen · von der KI geprüft.