02 · From Zero to Deployed

Fast jede Frage „Warum geht das nicht?“ lässt sich auf eine zurückführen: Welche Seite ist gerade dran — vorne oder hinten? Wer das benennt, findet Fehler schneller und lenkt den Agenten gezielter.

Die Idee

Denk an ein Restaurant. Der Gastraum ist, was du siehst: Tische, Speisekarte, Kellner. Die Küche ist versteckt: dort wird gekocht und gelagert. Du redest nur mit dem Kellner, nie direkt mit der Küche.

Bei Instagram ist der Feed, den du scrollst, der Gastraum — hübsch, schnell, in deiner Hand. Die Küche ist der Server, der irgendwo in einem Rechenzentrum steht und alle Beiträge und Likes aufbewahrt. Du siehst die Küche nie, aber jeder Beitrag im Feed kommt von dort.

Vorne = Frontend (Gastraum). Hinten = Backend (Küche). Der Kellner trägt die Bestellung hin und das Essen zurück.

So funktioniert es

Das Frontend läuft im Browser, zeigt Informationen an und sammelt deine Eingaben: der Feed, das Herz, das Textfeld für die Bildunterschrift.
Das Backend läuft auf einem entfernten Server, merkt sich Daten und setzt Regeln durch: es speichert einen Beitrag, zählt Likes, liefert den Feed.

Sie reden über Nachrichten: Das Frontend schickt eine Anfrage, das Backend antwortet. Willst du den Feed sehen, fragt dein Frontend zum Beispiel GET /feed an, und das Backend antwortet mit einer Liste von Beiträgen:

GET /feed HTTP/1.1
Host: instagram.example
Authorization: Bearer <token>

HTTP/1.1 200 OK
Content-Type: application/json

[
  { "id": "p_184029", "author": "anna", "caption": "Sonnenuntergang über Berlin", "likeCount": 12 },
  { "id": "p_184028", "author": "ben",  "caption": "Erster Kaffee",             "likeCount": 3  }
]

Der Clou der Aufteilung: Viele Frontends, ein Backend. Dein Handy, mein Laptop und tausend andere sehen denselben Feed, weil ein Backend die Wahrheit hält und ihn an alle ausliefert.

sequenceDiagram
    participant F as Frontend (Browser)
    participant B as Backend (Server)
    F->>B: GET /feed
    B-->>F: 200 OK + Liste von Beiträgen
    F->>B: POST /api/posts (neuer Beitrag)
    B-->>F: 201 Created + gespeicherter Beitrag

So steuerst du es

Merksatz: Vertraue dem Frontend nie. Alles, was beim Backend ankommt, kann gefälscht sein — jemand könnte den Request von Hand bauen. Der Server muss jede Eingabe prüfen und alle Regeln selbst durchsetzen. Das Frontend ist für Bequemlichkeit da, das Backend für Wahrheit und Sicherheit.

Das Backend ist außerdem die einzige Quelle der Wahrheit. Ein typischer Fehler ist, den Zustand doppelt zu halten: Das Frontend zeigt 13 Likes, weil du gerade getippt hast, aber das Backend hat den Klick nie gespeichert. Regel: Das Frontend spiegelt nur, was das Backend bestätigt hat.

So sagst du es dem Agenten:

„Ist das eine Frontend- oder eine Backend-Aufgabe? Erkläre kurz, bevor du es baust.“

„Sorge dafür, dass das Backend jede Eingabe prüft — verlass dich nicht auf Prüfungen im Frontend.“

„Aktualisiere die Like-Zahl im Frontend erst, nachdem das Backend den Like bestätigt hat.“

Typische Fehler: Prüfungen nur im Frontend; Frontend und Backend zeigen widersprüchliche Zustände; oder Geschäftslogik (wer darf was) in den Client legen.

Kurz-Check

Wofür ist das Frontend zuständig, wofür das Backend?
Warum können viele Nutzer denselben Feed sehen?
Warum darf man dem Frontend nicht vertrauen?

Antworten anzeigen

Frontend: anzeigen und Eingaben sammeln. Backend: speichern, zählen, Regeln durchsetzen, den Feed liefern.
Weil ein einziges Backend die Wahrheit hält und den Feed an alle Frontends ausliefert.
Weil es öffentlich und manipulierbar ist; nur der Server kann Daten und Regeln verbindlich durchsetzen.

Almost every "why doesn't this work?" reduces to one question: which side is doing this — front or back? Naming it finds bugs faster and steers the agent more precisely.

The idea

Think of a restaurant. The dining room is what you see: tables, menu, waiter. The kitchen is hidden: cooking and storage happen there. You only talk to the waiter, never straight to the kitchen.

On Instagram, the feed you scroll is the dining room — pretty, fast, in your hand. The kitchen is the server sitting somewhere in a data center, keeping every post and like. You never see the kitchen, but every post in the feed comes from there.

Front = frontend (dining room). Back = backend (kitchen). The waiter carries the order in and the food back.

How it works

The frontend runs in the browser, shows information, and collects your input: the feed, the heart, the caption field.
The backend runs on a remote server, remembers data, and enforces rules: it saves a post, counts likes, returns the feed.

They talk through messages: the frontend sends a request, the backend answers. To see the feed, your frontend asks, say, GET /feed, and the backend replies with a list of posts:

GET /feed HTTP/1.1
Host: instagram.example
Authorization: Bearer <token>

HTTP/1.1 200 OK
Content-Type: application/json

[
  { "id": "p_184029", "author": "anna", "caption": "Sunset over Berlin", "likeCount": 12 },
  { "id": "p_184028", "author": "ben",  "caption": "First coffee",       "likeCount": 3  }
]

The point of the split: many frontends, one backend. Your phone, my laptop, and a thousand others see the same feed because one backend holds the truth and serves it to everyone.

sequenceDiagram
    participant F as Frontend (browser)
    participant B as Backend (server)
    F->>B: GET /feed
    B-->>F: 200 OK + list of posts
    F->>B: POST /api/posts (new post)
    B-->>F: 201 Created + saved post

How you steer it

Rule of thumb: never trust the frontend. Anything that arrives at the backend can be forged — someone could craft the request by hand. The server must check every input and enforce every rule itself. The frontend is for convenience, the backend for truth and safety.

The backend is also the single source of truth. A typical bug is holding state twice: the frontend shows 13 likes because you just tapped, but the backend never saved the click. Rule: the frontend only mirrors what the backend confirmed.

How to tell the agent:

"Is this a frontend or a backend task? Explain briefly before you build it."

"Make sure the backend checks every input — do not rely on frontend checks."

"Only update the like count in the frontend after the backend confirms the like."

Common mistakes: checks only in the frontend; frontend and backend showing contradictory state; or putting business logic (who may do what) into the client.

Quick check

What is the frontend responsible for, and what the backend?
Why can many users see the same feed?
Why must you not trust the frontend?

Show answers

Frontend: show and collect input. Backend: store, count, enforce rules, serve the feed.
Because a single backend holds the truth and serves the feed to all frontends.
Because it is public and tamperable; only the server can enforce data and rules for real.

02 · Frontend vs Backend