← From Zero to Deployed Alle LektionenAll lessons Setup ModelleModels

Phase 1 · Grundlagen

01 · Was ist eine Anwendung?

Du kannst erklären, was eine App ist und aus welchen Teilen sie besteht.

Phase 1 · Foundations

01 · What is an Application?

You can explain what an app is and name the parts it is made of.

Wenn du mit einem Coding-Agenten baust, musst du ihm sagen, welchen Teil der App er ändern soll. „Mach den Like-Button größer“ ist etwas völlig anderes als „merke dir das Foto auch nach dem Neuladen“. Wer die Teile kennt, gibt klarere Anweisungen — und versteht die Antworten des Agenten.

Die Idee

Eine App ist ein Werkzeug, das auf einem Computer oder Handy läuft. Fast jede App spielt dasselbe Spiel: Du gibst etwas hinein, sie überlegt kurz, sie zeigt dir ein Ergebnis.

Stell dir einen Getränkeautomaten vor: Du drückst einen Knopf (hinein), der Automat entscheidet, welche Dose fällt (überlegen), und die Dose kommt heraus (Ergebnis).

Genau so funktioniert Instagram, das wir in diesem Kurs durchgehend als Beispiel nehmen: Du tippst auf das Herz unter einem Foto (hinein), Instagram merkt sich deinen Like und zählt ihn (überlegen), und die Zahl unter dem Foto wächst (Ergebnis). Ob Like, Kommentar oder neuer Beitrag — es ist immer dieselbe kleine Schleife.

flowchart LR
    I[Input
Tippen, Schreiben, Klicken] --> L[Logik
die App entscheidet]
    L --> O[Output
Ergebnis auf dem Bildschirm]

So funktioniert es

Fachlich heißt diese Schleife Input → Logik → Output: Eingabe, Verarbeitung, Ausgabe. Und jede App hat zwei Hälften:

Apps laufen an verschiedenen Orten. Manche installierst du (die Instagram-App aus dem App-Store), manche öffnest du im Browser (instagram.com). In diesem Kurs bauen wir eine Web-App — sie öffnet sich per Link, ohne Installation.

Was merkt sich das Backend über einen einzigen Instagram-Beitrag? Ungefähr das hier — in einem Format namens JSON (labelierter Text, für Mensch und Maschine lesbar):

{
  "id": "p_184029",
  "author": "anna",
  "caption": "Sonnenuntergang über Berlin",
  "imageUrl": "https://cdn.example/p/a1b2.jpg",
  "likeCount": 0,
  "createdAt": "2026-08-31T09:41:00Z"
}

Jedes Feld ist eine Tatsache über den Beitrag: eine eindeutige id, wer ihn gepostet hat (author), der Text (caption), wo das Foto liegt (imageUrl), wie viele Likes er hat (likeCount) und wann er entstand (createdAt). Dieses Objekt begleitet uns durch den ganzen Kurs.

flowchart LR
    F[Frontend
Feed, Like-Button] -->|Beitrag posten| B[Backend
speichern, zählen]
    B -->|Feed zurückgeben| F

So steuerst du es

Präziser: Eine Anwendung ist Software, die einen Zustand hält (die gespeicherten Beiträge) und auf Ereignisse reagiert (ein Like, ein neuer Beitrag). Die wichtige Grenze verläuft zwischen Client (läuft im Browser der Nutzerin, ist öffentlich sichtbar und manipulierbar) und Server (läuft entfernt, dir gehört die Kontrolle).

Regel: Alles, was geheim oder verbindlich sein muss, gehört auf den Server. Ein klassischer Anfängerfehler ist, eine Regel wie „nur der Autor darf seinen Beitrag löschen“ nur im Frontend zu prüfen — das lässt sich umgehen, weil jeder den Client verändern kann. Der Server muss die Regel selbst durchsetzen.

Wenn du dem Agenten Aufgaben gibst, benenne immer die Ebene:

„Baue eine einfache Web-App als Frontend plus kleines Backend für Instagram-Beiträge. Beschreibe mir zuerst kurz, welche Teile du anlegst.“

„Ordne diese Änderung ein: gehört sie ins Frontend (was man sieht) oder ins Backend (was gespeichert und geprüft wird)?“

„Setze die Regel ‚nur der Autor darf löschen‘ im Backend durch, nicht nur im Frontend.“

Typische Fehler: die Ebenen verwechseln; Logik in den Client legen, die auf den Server gehört; oder annehmen, dass „sieht im Browser richtig aus“ dasselbe ist wie „ist wirklich gespeichert“.

Kurz-Check

  1. Was bedeutet „Input → Logik → Output“ am Beispiel eines Instagram-Likes?
  2. Was ist der Unterschied zwischen Frontend und Backend?
  3. Warum gehört „nur der Autor darf löschen“ auf den Server?
Antworten anzeigen
  1. Du tippst auf das Herz (Input), Instagram zählt den Like (Logik), die Zahl steigt (Output).
  2. Frontend = was man sieht und bedient (Feed, Buttons); Backend = der versteckte Teil, der speichert, zählt und Regeln durchsetzt.
  3. Weil der Client öffentlich und manipulierbar ist; nur der Server kann die Regel wirklich erzwingen.

When you build with a coding agent, you have to tell it which part of the app to change. "Make the like button bigger" is completely different from "remember the photo after a reload". Knowing the parts lets you give clear instructions — and understand the agent's answers.

The idea

An app is a tool that runs on a computer or phone. Almost every app plays the same game: you put something in, it thinks for a moment, it shows you a result.

Picture a vending machine: you press a button (in), the machine decides which can to drop (think), and the can comes out (result).

This is exactly how Instagram works — our running example for the whole course. You tap the heart under a photo (in), Instagram records your like and counts it (think), and the number under the photo grows (result). Whether it is a like, a comment, or a new post, it is always the same small loop.

flowchart LR
    I[Input
tap, type, click] --> L[Logic
the app decides]
    L --> O[Output
result on the screen]

How it works

Technically this loop is called input → logic → output. And every app has two halves:

Apps run in different places. Some you install (the Instagram app from the app store), some you open in a browser (instagram.com). In this course we build a web app — it opens from a link, with nothing to install.

What does the backend remember about a single Instagram post? Roughly this — in a format called JSON (labelled text, readable by humans and machines):

{
  "id": "p_184029",
  "author": "anna",
  "caption": "Sunset over Berlin",
  "imageUrl": "https://cdn.example/p/a1b2.jpg",
  "likeCount": 0,
  "createdAt": "2026-08-31T09:41:00Z"
}

Every field is a fact about the post: a unique id, who posted it (author), the text (caption), where the photo lives (imageUrl), how many likes it has (likeCount), and when it was created (createdAt). This object follows us through the whole course.

flowchart LR
    F[Frontend
feed, like button] -->|create a post| B[Backend
save, count]
    B -->|return the feed| F

How you steer it

More precisely: an application is software that holds state (the stored posts) and reacts to events (a like, a new post). The important boundary runs between the client (runs in the user's browser, is publicly visible and tamperable) and the server (runs remotely, you control it).

Rule: anything that must be secret or enforced belongs on the server. A classic beginner mistake is to check a rule like "only the author may delete their post" only in the frontend — that can be bypassed, because anyone can modify the client. The server has to enforce the rule itself.

When you give the agent tasks, always name the layer:

"Build a simple web app with a frontend plus a small backend for Instagram posts. First describe briefly which parts you will create."

"Classify this change: does it belong in the frontend (what people see) or the backend (what is stored and checked)?"

"Enforce the rule 'only the author may delete' in the backend, not just in the frontend."

Common mistakes: confusing the layers; putting logic in the client that belongs on the server; or assuming that "looks right in the browser" is the same as "is actually stored".

Quick check

  1. What does "input → logic → output" mean for an Instagram like?
  2. What is the difference between frontend and backend?
  3. Why does "only the author may delete" belong on the server?
Show answers
  1. You tap the heart (input), Instagram counts the like (logic), the number goes up (output).
  2. Frontend = what you see and operate (feed, buttons); backend = the hidden part that stores, counts, and enforces rules.
  3. Because the client is public and tamperable; only the server can truly enforce the rule.