Was ist ein Backend? Die Serverseite einer Anwendung, erklärt

Ein Backend ist ein serverseitiges System: Code, Datenbank und Infrastruktur, die hinter der Oberfläche Anfragen einer App verarbeiten und ihre Daten speichern. Jede Software mit Benutzern hat zwei Hälften. Die Hälfte, die sie sehen und berühren – Screens, Buttons, Formulare –, ist das Frontend.

Die Hälfte, die sie nie sehen – die entscheidet, was die Buttons dürfen, und sich merkt, was passiert ist, nachdem die App geschlossen wurde –, ist das Backend. Die alte Mechaniker-Analogie trägt noch immer: Der Fahrer bedient das Armaturenbrett, der Mechaniker arbeitet am Motor.

Dieser Eintrag handelt vom Motor.

Das Wichtigste in Kürze

Eine Anfrage, von Anfang bis Ende

Am klarsten sieht man ein Backend, wenn man eine einzelne Anfrage hindurch verfolgt. Ein Benutzer tippt auf “Meine offenen Aufgaben anzeigen”; das passiert auf der anderen Seite der API:

GET /classes/Todo?where={"done":false} HTTP/1.1    ← das Frontend fragt
Authorization: Bearer eyJhbGci…                     ← wer da fragt

  Backend ─┬─ API-Schicht      Anfrage parsen, Token prüfen
           ├─ Autorisierung    darf dieser Benutzer diese Zeilen lesen?
           ├─ Geschäftslogik   Regeln anwenden (nur die Aufgaben des Aufrufers)
           ├─ Datenschicht     Datenbank abfragen, Ergebnis formen
           └─ Antwort          200 OK + JSON, in unter 100 ms

{ "results": [ { "objectId": "xKd91m", "title": "Ship the release", "done": false } ] }

Dasselbe Gespräch von der Frontend-Seite aus, über ein SDK, das daraus pro Plattform eine Zeile macht:

// JavaScript / Node.js — Back4app JS SDK
// The frontend asks the backend a question; the backend answers from the database
const query = new Parse.Query('Todo');
query.equalTo('done', false);
const open = await query.find();
// Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
console.log(`${open.length} open todos`);

// Flutter / Dart — Back4app Flutter SDK
// The frontend asks the backend a question; the backend answers from the database
final query = QueryBuilder<ParseObject>(ParseObject('Todo'))
  ..whereEqualTo('done', false);
final response = await query.query();
// Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
print('${response.results?.length ?? 0} open todos');

// iOS / Swift — Back4app Swift SDK
// The frontend asks the backend a question; the backend answers from the database
let query = Todo.query("done" == false)
query.find { result in
    // Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
    if case .success(let open) = result { print("\(open.count) open todos") }
}

// Android / Kotlin — Back4app Android SDK
// The frontend asks the backend a question; the backend answers from the database
val query = ParseQuery.getQuery<ParseObject>("Todo")
query.whereEqualTo("done", false)
query.findInBackground { open, e ->
    // Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
    if (e == null) println("${open.size} open todos")
}

Frontend vs. Backend

Die Unterscheidung, nach der am häufigsten gesucht wird, in einer Tabelle:

Die letzte Zeile ist die, die für die Sicherheit zählt: Alles im Frontend kann der Benutzer lesen und verändern. Deshalb gehören Validierung, Berechtigungen und Geheimnisse ins Backend, und deshalb gilt jeder API-Aufruf als nicht vertrauenswürdig, bis der Server ihn geprüft hat.

Clientseite und Serverseite

Die beiden Begriffe sind keine zwei Arten von Backend, sondern die zwei Enden jeder Anfrage. Die Clientseite ist der Code, der auf dem Gerät des Benutzers läuft – er rendert die Oberfläche, hält temporären Zustand, sendet Anfragen.

Die Serverseite ist der Code, der auf Maschinen läuft, die der Benutzer nicht erreichen kann – er nimmt diese Anfragen entgegen, führt die eigentliche Logik aus, liest und schreibt die Datenbank und antwortet. “Backend” und “Serverseite” werden für diese zweite Hälfte synonym verwendet, und dieser Eintrag hält es genauso.

Woraus ein Backend besteht

Die klassische Darstellung nennt das Frontend die Präsentationsschicht und das Backend die Datenzugriffsschicht und beschreibt das Backend als Zusammenspiel von drei Dingen: der Hardware, der darauf laufenden Software und der Netzwerkinfrastruktur zwischen beiden und dem Benutzer.

Das stimmt nach wie vor, nützlicher ist es aber, ein Backend als Stapel von Verantwortlichkeiten zu lesen, von denen die meisten in jedem Produkt vorkommen, unabhängig von seiner Größe:

• API-Schicht – der öffentliche Vertrag: REST- oder GraphQL-Endpoints, die das Frontend und andere Systeme aufrufen.
• Geschäftslogik – die Regeln, die das Produkt zum Produkt machen: was eine gültige Bestellung ist, wer was freigeben darf, wie ein Score berechnet wird.
• Datenschicht – die Datenbank und der Code, der sie modelliert, abfragt und migriert.
• Authentifizierung und Autorisierung – wer der Aufrufer ist und was er darf, durchgesetzt bei jeder Anfrage.
• Hintergrundarbeit – Jobs und Zeitpläne für alles, was keine Anfrage blockieren sollte: E-Mails, Berichte, Synchronisierungen, Aufräumarbeiten.
• Infrastruktur – die Server, Container oder Funktionen, auf denen das alles läuft, plus Deployment, Logging, Monitoring, Backups und Skalierung.

Die ersten fünf sind Produktarbeit. Die sechste ist Betrieb – und genau der Teil, den moderne Hosting-Modelle abnehmen sollen.

Backend-Architekturen

Die ursprüngliche Fassung dieses Themas beschrieb drei Familien – Serverless, serverorientiert und dezentral –, und die Taxonomie gilt noch immer. Geändert hat sich der Standard: 2026 beginnen die meisten neuen Produkte in der Serverless-Familie, und “serverorientiert” bedeutet zunehmend Container statt Maschinen.

Serverbasierte Backends. Ihr Team stellt Maschinen, virtuelle Maschinen oder Container bereit, installiert eine Runtime und eine Datenbank und betreibt sie. Maximale Kontrolle, maximale Verantwortung: Kapazität, Patches, Verfügbarkeit und die Rufbereitschaft liegen bei Ihnen.

Die klassischen Argumente dafür gelten weiterhin – ein Ort, der Daten zwischen mehreren Anwendungen teilt, unkomplizierte Integrationen, ein einziger abzusichernder Zugangspunkt –, und die Form im Inneren kann ein Monolith oder Microservices sein; das Betriebsmodell ist dasselbe.

Serverless-Backends. Ein Anbieter betreibt die Infrastruktur und rechnet nach Nutzung ab. Zwei Varianten: Function as a Service, bei der Sie eigenen Code als Funktionen deployen, die von null skalieren, und Backend as a Service, bei dem Datenbank, Auth, APIs, Speicher und Funktionen als verwaltete Plattform kommen.

Der Gewinn ist Geschwindigkeit – keine Server, die vor dem ersten Feature aufgebaut werden müssen –, der Preis ist die Kontrolle über die untersten Schichten. Die vollständige Leiter der Hosting-Modelle vergleicht IaaS vs. PaaS vs. BaaS vs. FaaS.

Dezentrale Backends. Kein einzelner Betreiber; der Zustand liegt in einem Peer-to-Peer-Netzwerk, meist Open Source, wie bei Blockchains und inhaltsadressiertem Speicher. Bitcoin und Ethereum sind die kanonischen Beispiele, und das Frontend einer solchen App wird oft auf dieselbe Weise gehostet – in Netzwerken wie IPFS oder Swarm statt auf einem Server.

Zensurresistenz und kein zentraler Kontrollpunkt, um den Preis von Latenz, Durchsatz und einem völlig anderen Programmiermodell. Eine Nische mit echten Anwendungen, kein Allzweckersatz für die anderen beiden.

Serverbasiert vs. Serverless vs. BaaS vs. dezentral

Typische Anwendungsfälle

• Mobile und Web-Apps – Konten, Daten, die die Session überdauern, und Synchronisierung über Geräte hinweg brauchen alle eine Serverseite.
• Mehrbenutzer-Produkte – alles, bei dem die Aktion eines Benutzers für einen anderen sichtbar werden muss: Zusammenarbeit, Marktplätze, Chat.
• Zahlungen und sensible Operationen – Geheimnisse und Geld gehören nie auf das Gerät; das Backend hält die Schlüssel und spricht mit den Anbietern.
• Integrationen und Automatisierung – Webhooks, geplante Jobs und Pipelines, die laufen, ob gerade ein Benutzer online ist oder nicht.
• KI-Features – Modellaufrufe, Retrieval und Tool-Ausführung laufen serverseitig, wo Schlüssel privat bleiben und Ergebnisse gecacht und auditiert werden können.

Welchen Backend-Ansatz sollten Sie wählen? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Im Backend werden Fehler zum Problem aller. Ein Frontend-Bug macht einen Screen kaputt; ein Backend-Bug beschädigt Daten oder legt sie offen. Validierung, Berechtigungen und Tests wiegen hier schwerer als an jeder anderen Stelle der Codebasis.
• Betrieb verschwindet nie – er wandert nur. Verwaltete Plattformen nehmen Server, Skalierung und Backups ab, aber jemand verantwortet weiterhin das Datenmodell, die Zugriffsregeln und das Budget. Wählen Sie ein Modell nach den Verantwortlichkeiten, die Sie behalten wollen, nicht nach denen, die Sie vergessen möchten.
• Kontrolle und Geschwindigkeit ziehen in entgegengesetzte Richtungen. Je mehr vom Stack Sie selbst betreiben, desto mehr können Sie anpassen und desto länger dauert alles; je weniger Sie betreiben, desto schneller liefern Sie und desto stärker hängen Sie von Roadmap und Preisen eines Anbieters ab.
• Das Netzwerk ist Teil des Vertrags. Jeder Aufruf vom Frontend zum Backend kann langsam sein, auf halbem Weg scheitern oder doppelt ankommen; Latenzbudgets, Wiederholungsversuche und Idempotenz sind Backend-Themen vom ersten Endpoint an.
• “Serverless” hat trotzdem Server. Cold Starts, Ausführungslimits und nutzungsbasierte Abrechnung sind echte Einschränkungen; es sind schlicht die Maschinen von jemand anderem mit einer anderen Kostenkurve.

Das Backend mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert.

Auf die Schichten oben abgebildet: Datenschicht und API-Schicht werden aus Ihrem Datenmodell generiert, Authentifizierung und Klassenberechtigungen setzen bei jeder Anfrage durch, wer was darf, Cloud Code enthält die Geschäftslogik und die Hintergrund-Jobs, die für Ihr Produkt spezifisch sind, und die Infrastrukturschicht – Hosting, Skalierung, Backups, Monitoring – ist Sache der Plattform.

Die oben zerlegte Anfrage ist echtes Back4app-Wire-Format, und die SDKs, die sie gesendet haben, sind der Weg, auf dem das Frontend von jeder wichtigen Plattform aus mit diesem Backend spricht.