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.
Geprüftes Siegel
Erkläre Nova das Backend, das du für eine kleine App bauen würdest: Welche Schichten, welches Datenmodell (Tabellen + Beziehungen), wie ein zentraler Endpunkt aufgebaut ist (Auth → Validierung → Berechtigung → DB → Antwort, mit Status-Codes), und wie du DB & Auth sicher anbindest (RLS, Schlüssel-Trennung). Wo würde es ohne diese Struktur unsicher oder chaotisch?
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.