Begriff
Backend
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Eine App ist wie ein Restaurant.
- Frontend: Der prächtige Gastraum, die Speisekarte, der Kellner. (Was du siehst).
- Backend: Die Küche, das Lager, die Buchhaltung. (Was im Hintergrund passiert). Wenn du in der App auf "Kaufen" drückst, passiert im Frontend wenig (nur eine Lade-Animation). Das Backend prüft: "Ist Geld da? Ist Ware da?" und speichert die Bestellung in der Datenbank. Das Backend läuft auf dem Server, weit weg vom User, wo es sicher ist.
Merksatz: Der serverseitige Teil einer Softwareanwendung, der für Datenverarbeitung, Geschäftslogik, Datenbankzugriffe und APIs zuständig ist und für den Benutzer unsichtbar bleibt.
Sprachen: Python (Django/FastAPI), Java (Spring), JavaScript (Node.js), Go, PHP.
Komponenten:
- Webserver: Nimmt Anfragen entgegen (Nginx).
- App-Server: Führt Logik aus ("Berechne Preis").
- Datenbank: Speichert Daten dauerhaft (PostgreSQL).
- Cache: Speichert heiße Daten im RAM (Redis).
- Queue: Verwaltet Hintergrund-Jobs ("Email senden") (RabbitMQ).
Praxisroutine
In der Praxis lernst du Backend, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.
Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.
1. Stateless vs. Stateful
- Stateful: Der Server merkt sich im RAM, wer du bist ("Session"). Problem: Wenn der Server neustartet, sind alle ausgeloggt. Skaliert schlecht (User muss immer auf denselben Server).
- Stateless: Der Server vergisst alles sofort nach der Antwort. Du musst immer wieder dein Token (JWT) mitschicken. Skaliert perfekt (beliebiger Server kann antworten). Moderner Standard (REST).
2. Microservices
Monolith (Küche macht Pizza UND Sushi): Einfach zu starten, schwer zu ändern. Wenn der Pizzaofen brennt, gibt's auch kein Sushi. Microservices (Pizza-Stand und Sushi-Stand): Getrennte Backends, die miteinander reden. Vorteil: Teams arbeiten unabhängig. Pizza-Team macht Update, Sushi läuft weiter. Nachteil: Komplexität ("Distributed Monolith Hell").
3. Serverless (FaaS)
Kein Backend-Server mehr managen.
Du lädst nur eine Funktion hoch (check_price()).
Amazon (AWS Lambda) startet den Server nur für die 100 Millisekunden, wenn jemand die Funktion aufruft.
Du zahlst exakt für die Rechenzeit.
Billig bei wenig Last, teuer bei Dauerlast.
1. N-Tier Architecture und Hexagonal
Moderne Backends werden in Schichten gebaut.
Spaghetticode greift vom HTTP-Router direkt in die Datenbank (SELECT * FROM users).
Professionelle Architektur teilt auf (N-Tier):
- Controller Layer: Nimmt den HTTP-Request an, validiert das JSON (JavaScript Object Notation).
- Service Layer: Business-Logik ("Darf der User diesen Rabatt nutzen?").
- Data Access Layer (Repository): Spricht mit der Datenbank. Noch moderner ist die Hexagonale Architektur (Ports and Adapters). Dort hängt die Logik (im Kern) nicht mehr von der Datenbank ab, sondern definiert Interfaces (Ports). Die Datenbank ist nur ein austauschbarer "Adapter", den man ansteckt.
2. Message Brokers und Asynchronität
Wenn der User auf "Registrieren" klickt, muss das Backend den User anlegen, ihm eine Bestätigungs-EierMail schicken, ihn an Stripe (Payment) melden und ein PDF-Willkommensdokument rendern.
Wenn das alles "In-Band" (synchron) im Haupt-Thread von Knotenpunkt zu Knotenpunkt wandert, wartet der User 5 Sekunden auf den HTTP-Response (und klickt frustriert dreimal auf Regisitrieren -> Duplikate).
Die Lösung: Queues (z.B. RabbitMQ, Kafka).
Der HTTP-Router legt den User im DB an, wirft eine Nachricht in die Queue ("User angemeldet") und meldet dem Frontend sofort 201 Created (Dauer: 0.1 Sekunden).
Im Hintergrund greifen sich abgetrennte "Worker" die Nachricht aus der Queue und rendern das PDF, ohne den User-Thread zu blockieren.
3. Skalierung: Vertikal vs. Horizontal
Dein Server bricht unter Last zusammen.
- Vertikal Skalieren (Scale Up): Du kaufst einen doppelt so teuren Server mit doppelt so viel RAM und CPU. Das Limit (Hardware) ist schnell erreicht.
- Horizontal Skalieren (Scale Out): Du kaufst 10 billige Server und stellst einen Load Balancer davor. Wenn ein Server stirbt, machen 9 weiter. Voraussetzungen: Deine App muss konsequent stateless sein. Dateiuploads dürfen nicht mehr auf der lokalen Festplatte (C:/) liegen, sondern auf geteiltem Cloud-Storage (S3), da der nächste Request vielleicht von Server 8 bedient wird, wo die Datei sonst fehlen würde.
Quick-Check
BFF (Backend for Frontend)?
Ein Design Pattern. Statt einer Riesen-API gibt es spezielle Mini-Backends: Eines für die iOS-App (liefert kleine Bilder), eines für Desktop (liefert viele Details).ORM?
Object Relational Mapper. Ein Tool im Backend, das Python-Objekte automatisch in SQL-Befehle übersetzt. Spart Zeit, frisst Performance, wenn man nicht aufpasst (N+1 Problem).Headless CMS?
Ein Backend-Only CMS (Content Management System). Es hat kein Frontend (keine Webseite). Es liefert nur JSON per API. Das Frontend baut sich der Entwickler selbst (z. B. mit React).