Was ist eine Full-Stack-App? Eine verständliche Erklärung

Eine Full-Stack-App ist eine App, die alle Schichten enthält, die sie zum Funktionieren braucht: das Frontend, das Menschen sehen und anklicken, das Backend, das auf einem Server läuft und die Regeln durchsetzt, und die Datenbank, die alles speichert. Eine To-do-Liste, die deine Aufgaben speichert, dich von jedem Gerät aus anmelden lässt und niemand anderem deine Liste zeigt, ist Full-Stack. Eine einzelne Seite, die nur deine Öffnungszeiten zeigt, ist es nicht.

„Stack“ bezeichnet einfach die Schichten der Technik, die aufeinandergestapelt sind. „Full“ heißt, dass alle vorhanden sind.

Warum das beim Bauen mit KI wichtig ist

Wenn du einem KI-Builder eine App beschreibst, entscheiden deine Worte, welche Schichten gebaut werden. „Mach eine Seite, die unsere Speisekarte zeigt“ ergibt ein Frontend. „Lass Kundinnen aus unserer Speisekarte bestellen und lass die Küche neue Bestellungen sehen“ braucht alle drei Schichten, weil Bestellungen gespeichert, zwischen zwei Arten von Nutzern geteilt und privat gehalten werden müssen.

Der Unterschied hilft dir in drei Punkten:

• Du fragst das Richtige ab. Wenn Daten gespeichert werden sollen, sag es. Ein Builder, der nur das Frontend baut, sieht fertig aus, vergisst aber alles beim Neuladen.
• Du erkennst scheinbare Vollständigkeit. Eine Demo mit Beispieldaten kann genauso aussehen wie eine funktionierende App. Wer die Schichten kennt, kann prüfen, ob die Daten wirklich irgendwo ankommen.
• Du verstehst die laufenden Kosten. Ein reines Frontend lässt sich als statische Dateien ausliefern. Backend und Datenbank sind Programme, die auf Servern laufen, und dort entstehen die meisten Hosting-Kosten.

Ein Alltagsvergleich: ein Restaurant

Stell dir ein Restaurant vor.

• Der Gastraum ist das Frontend. Speisekarten, Tische und der Notizblock der Kellnerin. Er ist das, was die Gäste sehen, und sollte angenehm und leicht zu bedienen sein.
• Die Küche ist das Backend. Gäste gehen nie hinein. Sie nimmt Bestellungen an, prüft, ob ein Gericht verfügbar ist, kocht es und lehnt seltsame Wünsche ab. Hier leben die Regeln.
• Vorratskammer und Bestellbuch sind die Datenbank. Sie halten fest, was es gibt und was bestellt wurde, damit beim Schichtwechsel nichts vergessen wird.

Ein Restaurant nur mit Gastraum kann dir eine schöne Speisekarte zeigen, aber du bekommst nichts zu essen. Das ist eine App, die nur aus dem Frontend besteht und so tut, als wäre sie Full-Stack.

Die drei Schichten im Detail

Die Schichten sprechen in fester Reihenfolge miteinander. Das Frontend bittet das Backend über eine API um etwas, eine festgelegte Menge an Anfragen, die das Backend annimmt. Das Backend prüft die Anfrage, liest oder schreibt in die Datenbank und schickt eine Antwort zurück. Das Frontend spricht nie direkt mit der Datenbank.

Diese Reihenfolge ist die wichtigste Sicherheitsidee im ganzen Stack. Alles im Frontend kann der Besucher lesen und ändern, weil es auf seinem Gerät läuft. Deshalb müssen die Regeln („nur der Besitzer darf diese Rechnung sehen“, „ein Gutschein ist nur einmal einlösbar“) im Backend durchgesetzt werden. Mehr zur Aufteilung findest du unter Frontend vs. Backend.

Ein Beispiel: eine App für Kursbuchungen

Nehmen wir an, du betreibst ein Yoga-Studio und möchtest, dass Menschen Kurse online buchen.

Was der Besucher tut: Er öffnet die Seite, sieht die Kurse dieser Woche, tippt einen an, meldet sich an und bucht einen Platz.

Was darunter passiert:

1. Das Frontend zeigt den Stundenplan. Um ihn zu füllen, fragt es das Backend: „Welche Kurse sind diese Woche, und wie viele Plätze sind frei?“
2. Das Backend fragt die Datenbank nach den Kursen und zählt die Buchungen für jeden, dann antwortet es.
3. Der Besucher tippt auf Buchen. Das Frontend sendet „buche Kurs 42 für diese angemeldete Person“.
4. Das Backend prüft: Ist diese Person wirklich angemeldet? Ist der Kurs voll? Hat sie ihn schon gebucht? Nur wenn alles stimmt, schreibt es eine neue Buchungszeile in die Datenbank.
5. Das Backend meldet „gebucht“, und das Frontend zeigt eine Bestätigung.
6. Später meldet sich die Studioinhaberin an und sieht die Kursliste. Das Backend prüft, dass sie Admin ist, bevor es alle Namen zeigt.

Stell dir nun vor, das wäre nur als Frontend gebaut. Der Stundenplan würde vielleicht angezeigt, und der Buchen-Button zeigte ein schönes Häkchen, aber die Buchung wäre beim Neuladen weg, die Anzeige „freie Plätze“ wäre für alle anderen falsch, und die Inhaberin würde sie nie sehen. Schritt 4, die Prüfungen, würde komplett fehlen. Darin liegt der praktische Unterschied.

Wichtige Begriffe

• Frontend (clientseitig): der Teil, der im Browser läuft.
• Backend (serverseitig): der Teil, der auf einem Server läuft. Auch API-Server genannt.
• Datenbank: der Ort, an dem Daten strukturiert gespeichert werden. Siehe was eine Datenbank ist.
• API: die Liste der Anfragen, die das Backend vom Frontend oder anderen Programmen annimmt.
• Authentifizierung: prüfen, wer jemand ist (Anmeldung). Autorisierung: prüfen, was diese Person tun darf.
• Deployment: alle Schichten auf Servern bereitstellen, damit die Öffentlichkeit sie nutzen kann.
• Monolith vs. Dienste: ein Programm, das alles tut, im Gegensatz zu mehreren kleineren (etwa einer Website und einer separaten API). Beides ist Full-Stack.

Häufige Fehler und Missverständnisse

• „Es sieht fertig aus, also ist es fertig.“ Beispieldaten und ein funktionierend wirkender Button sind nicht dasselbe wie gespeicherte Daten. Lade die Seite neu, öffne sie in einem privaten Fenster und prüfe, ob die Daten noch da sind.
• Regeln im Frontend ablegen. Einen Button auszublenden ist keine Sicherheit. Prüft das Backend nicht, kann jeder, der die Anfrage kennt, sie selbst senden.
• Geheime Schlüssel ins Frontend legen. Ein Schlüssel eines Zahlungs- oder KI-Anbieters im Browser-Code ist für jeden Besucher lesbar. Schlüssel gehören ins Backend, in Umgebungsvariablen, siehe Umgebungsvariablen und Secrets.
• Glauben, Full-Stack heiße kompliziert. Eine kleine Full-Stack-App kann aus wenigen Bildschirmen, einigen Backend-Routen und drei Datenbanktabellen bestehen. Es beschreibt die Schichten, nicht die Größe.
• Glauben, du musst jede Technik selbst auswählen. Für eine erste Version reicht jeder vernünftige, weit verbreitete Stack. Wichtiger ist eine klare Beschreibung der Daten und der Regeln.

Was du deinen KI-Builder fragen solltest

Beschreibe die App anhand der drei Schichten, auch wenn du sie nicht beim Namen nennst:

• Die Daten: „Speichere Kurse (Name, Zeit, Kapazität) und Buchungen (Kurs, Person, Buchungszeit) in einer Datenbank.“
• Die Regeln: „Ein Kurs kann nicht über die Kapazität hinaus gebucht werden. Eine Person kann einen Kurs nur einmal buchen. Nur Admins sehen, wer gebucht hat.“
• Die Bildschirme: „Ein Wochenstundenplan, eine Buchungsbestätigung, eine Admin-Seite mit den Buchungen pro Kurs.“
• Die Prüfungen: „Erzwinge diese Regeln auf dem Server, nicht nur auf der Seite. Halte alle API-Schlüssel auf dem Server.“

Dann teste skeptisch: neu laden, mit zwei verschiedenen Personen anmelden, versuchen, Daten zu sehen, die du nicht sehen solltest. Der Leitfaden zum Bauen einer App mit KI führt dich durch diesen Ablauf von Anfang bis Ende.

Full-Stack-Apps bei Mythex

Mythex baut Full-Stack-Webapps aus einer Chat-Beschreibung. Standardmäßig bekommt eine neue App ein Frontend mit React und TypeScript. Muss die App Daten speichern, fügt Mythex dem Projekt eine eigene Postgres-Datenbank hinzu, und du kannst zusätzlich zur Website einen eigenen API-Server anfordern, zum Beispiel mit Python, Node, C# oder Java. Alles läuft gemeinsam in einer Live-Vorschau und wird unter einer öffentlichen URL veröffentlicht. Die Dokumentationsseite zu Apps mit mehreren Diensten zeigt, wie eine Website und eine API gemeinsam in der Vorschau und bei der Veröffentlichung behandelt werden. Die Seite Full-Stack-App-Builder bietet Startpunkte.

Fragen