Wie VULK Backends automatisch generiert

Aktualisiert am 17. Juli 2026 — aufgefrischt mit verifizierten Plattformdaten dazu, wie viele KI-generierte Apps tatsächlich echte Backends bekommen.

Wie generiert VULK ein Backend automatisch?

Die vollständige Antwort: VULK liest Ihren Prompt auf Backend-Signale — Konten, gespeicherte Daten, Admin-Panels, APIs — und wenn es sie findet, generiert es eine vollständige serverseitige Anwendung neben Ihrem Frontend: ein relationales Datenbankschema (Tabellen, Fremdschlüssel, Indizes, Constraints), RESTful-CRUD-Endpunkte für jede Entität, JWT-basierte Authentifizierung mit bcrypt-Passwort-Hashing und ein Frontend, das bereits mit diesen Endpunkten verdrahtet ist — mit Tokens, Ladezuständen und Fehlerbehandlung. Kein Supabase-Konto, kein Firebase-Projekt, kein externes Setup — das Backend wird mit Ihrer App auf VULKs Infrastruktur deployt (ab Builder-Plan).

Das ist wichtig, weil „KI-App-Builder machen UI-Spielzeuge" inzwischen ein Mythos ist, und die Daten beweisen es: 62% aller auf VULK generierten Apps enthalten ein SQL-Datenbankschema, und 27% bekommen ein provisioniertes Backend — eine lebende API plus gehostete Datenbank. SQL ist der #3 der meistgenerierten Dateitypen auf der Plattform mit 6,1% von 124.755 Dateien, nur hinter TypeScript und JSON (VULK-Plattformdaten, Juli 2026, N = 11.355 Projekte). Die meisten „vibe-coded" Apps sind Datenanwendungen, keine statischen Seiten.

Was ist falsch an Frontend-only-KI-Buildern?

Die meisten KI-Codegeneratoren geben Ihnen eine React-App mit hartkodierten Daten. Das Login-Formular sieht hübsch aus, authentifiziert aber niemanden. Das Dashboard zeigt Diagramme mit statischem JSON, das sich nie ändert. Der „Speichern"-Button löst eine Toast-Benachrichtigung aus, speichert aber nichts.

Ich habe VULKs Backend-Generierung gebaut, weil ich es leid war, dieses Muster zu sehen. Ein Frontend ohne Backend ist ein Prototyp, keine Anwendung. Und wenn Sie für einen KI-Code-Builder bezahlen, sollten Sie etwas bekommen, das tatsächlich funktioniert.

Wenn Ihr Prompt Funktionalität beschreibt, die ein Backend erfordert — Benutzerkonten, gespeicherte Daten, API-Endpunkte, Admin-Panels — generiert VULK das Backend automatisch. Kein Mock. Ein echtes Backend mit relationaler Datenbank, API-Routen, Authentifizierung und Schema-Migrationen. Das Login-Formular loggt Sie tatsächlich ein. Die Daten bleiben tatsächlich bestehen. Die API-Endpunkte antworten tatsächlich.

Wie funktioniert die Backend-Erkennung?

Sie müssen nicht „generiere ein Backend" sagen. Sie beschreiben, was Sie wollen, und VULK bestimmt anhand von Signalen in Ihrem Prompt, ob ein Backend nötig ist.

Die Erkennung ist bewusst konservativ. VULK fügt einer einfachen Landing Page oder einem statischen Portfolio kein Backend hinzu. Sie aktiviert sich nur, wenn Ihr Prompt wirklich serverseitige Funktionalität verlangt. Die plattformweite Aufteilung spiegelt das wider: 62% der Apps bekommen ein Schema, während der Rest — Portfolios, Landing Pages, Spiele — echt Frontend-only bleibt (VULK-Plattformdaten, Juli 2026).

Warum PostgreSQL und nicht Supabase, Firebase oder MongoDB?

Ich werde oft nach dieser Entscheidung gefragt und will transparent über die Begründung sein.

Warum nicht Supabase oder Firebase? Weil es Drittanbieterdienste sind, die externe Abhängigkeiten schaffen. Würde ich Code generieren, der ein Supabase-Projekt erfordert, müssten Sie ein Supabase-Konto anlegen, ein Projekt aufsetzen, Umgebungsvariablen konfigurieren und einen weiteren Dienst verwalten. Das bricht das „Ein Prompt, eine funktionierende App"-Erlebnis. VULKs Backend läuft auf unserer Infrastruktur mit null externem Setup. (Wenn Sie Ihr eigenes Supabase wollen, gibt es das als Opt-in-Integration ab Pro+ — Sie verbinden Ihre Keys und der Agent arbeitet gegen Ihr echtes Projekt. Es wird Ihnen nur nie aufgezwungen.)

Warum nicht MongoDB? Weil die meisten Anwendungen, die VULK-Nutzer bauen, relational sind. Aufgaben gehören zu Projekten. Projekte gehören zu Nutzern. Bestellungen enthalten Bestellpositionen. Produkte haben Kategorien. Diese Beziehungen lassen sich natürlich als Tabellen mit Fremdschlüsseln ausdrücken, nicht als Dokumentsammlungen. MongoDB ist großartig für bestimmte Anwendungsfälle, aber für die Breite der Anwendungen, die VULK generiert, produzieren relationale Datenbanken saubereren, wartbareren Code.

Warum ausgerechnet PostgreSQL? Es ist die fähigste Open-Source-relationale Datenbank. Volle ACID-Konformität, exzellente JSON-Unterstützung für Flexibilität, robuste Indizierung und ein riesiges Ökosystem. Es ist, was ich für eine Produktionsanwendung wählen würde — also ist es das, was VULK generiert.

Was wird genau generiert?

Wenn die Backend-Generierung auslöst, produziert VULK eine vollständige serverseitige Anwendung neben Ihrem Frontend. Das enthält jede Schicht:

Datenbankschema. Vollständige SQL-Tabellen mit Spalten, Typen, Constraints, Indizes und Beziehungen. Eine Users-Tabelle bekommt id, email, password_hash, name, created_at und updated_at. Posts bekommen einen Fremdschlüssel zu den Nutzern. Jede Tabelle bekommt einen Primärschlüssel, Timestamps und Indizes auf den in Queries genutzten Spalten.

Die Spalte heißt password_hash — niemals password. Das ist eine bewusste Sicherheitsentscheidung, die ich im Prompt-Engineering erzwinge. Passwörter werden bei der Registrierung mit bcrypt gehasht und beim Login verglichen. Der Spaltenname selbst macht die Absicht unmissverständlich.

API-Endpunkte. RESTful-Routen für jede Entität Ihres Schemas. Eine posts-Tabelle generiert GET /api/posts (Liste mit Paginierung), GET /api/posts/:id (einzelner Datensatz), POST /api/posts (Erstellen), PUT /api/posts/:id (Aktualisieren) und DELETE /api/posts/:id (Löschen). Jeder Endpunkt enthält Eingabevalidierung, Fehlerbehandlung und passende HTTP-Statuscodes.

Authentifizierungssystem. Registrierung (POST /api/auth/register) und Login (POST /api/auth/login). Die Registrierung hasht das Passwort mit bcrypt und speichert es. Der Login vergleicht gegen den Hash und gibt ein JWT zurück. Geschützte Routen verifizieren das JWT via Middleware.

Frontend-Integration. Das ist der Teil, der alles komplett wirken lässt. Das React-Frontend wird mit bereits verdrahteten API-Aufrufen generiert. Fetch-Aufrufe zeigen auf die korrekten Endpunkte. Auth-Tokens werden gespeichert und an Requests angehängt. Ladezustände und Fehlerbehandlung sind enthalten. Das Login-Formular authentifiziert wirklich. Das Registrierungsformular erstellt wirklich ein Konto. Gespeicherte Daten bleiben wirklich über Sitzungen hinweg bestehen.

Wie sehen echte Backend-Generierungen aus?

Aufgabenmanagement-App: „Baue eine Aufgabenmanagement-App, in der Nutzer ein Konto anlegen, sich einloggen, Projekte erstellen und Aufgaben zu Projekten hinzufügen können. Aufgaben haben Titel, Beschreibung, Priorität, Fälligkeitsdatum und Status. Nutzer sehen nur ihre eigenen Projekte."

Das generiert: users-Tabelle, projects-Tabelle mit user_id-Fremdschlüssel, tasks-Tabelle mit project_id-Fremdschlüssel, Auth-Endpunkte, CRUD für Projekte und Aufgaben, Autorisierungs-Middleware, die nach user_id filtert.

E-Commerce-Shop: „Erstelle einen Online-Shop für handgemachte Keramik. Der Admin kann Produkte hinzufügen. Kunden können stöbern, in den Warenkorb legen und bestellen. Der Bestellverlauf wird im Nutzerkonto gespeichert."

Das generiert: users-Tabelle mit role-Spalte, products-Tabelle, orders-Tabelle, order_items-Verbindungstabelle, rollenbasierte Zugriffskontrolle, Admin-only-Endpunkte für die Produktverwaltung, Kunden-Endpunkte fürs Stöbern und Bestellen.

Diese beiden Beispiele sind keine handverlesenen Exoten — Dashboards/Admin-Panels (12,5%), E-Commerce (4,5%) und Buchungssysteme (3,4%) sind die Top-Kategorien mit Backend-Form, die Menschen tatsächlich generieren (VULK-Plattformdaten, Juli 2026).

Wie gut ist das generierte Datenbankschema?

Mir liegt Schema-Qualität am Herzen, weil schlechte Schemas schlechte Anwendungen erzeugen. Das erzwingt VULK:

Primärschlüssel nutzen der Einfachheit halber auto-inkrementierende Integer. UUID ist für spezifische Anwendungsfälle verfügbar.

Fremdschlüssel enthalten ON DELETE CASCADE, wo angemessen (das Löschen eines Nutzers löscht seine Posts), und ON DELETE SET NULL, wo verwaiste Datensätze überleben sollen (das Löschen einer Kategorie löscht keine Produkte).

Indizes werden auf Fremdschlüsselspalten, E-Mail-Spalten (für Login-Lookups) und jeder in WHERE- oder ORDER-BY-Klauseln genutzten Spalte angelegt. Das ist kein Nachgedanke — die generierten Indizes passen zu den generierten Queries.

Timestamps (created_at, updated_at) sind auf jeder Tabelle.

Enums und Constraints werden für begrenzte Werte genutzt. Ein Aufgabenstatus ist auf spezifische Werte beschränkt, nicht auf beliebige Strings.

Welche Sicherheitsmuster sind eingebaut?

Das machen die meisten bei generiertem Code falsch: Sie liefern ihn aus, ohne an Sicherheit zu denken. VULKs Backend-Generierung enthält Sicherheitsmuster standardmäßig, weil das Ausliefern ohne sie echte Schwachstellen schafft:

• Passwort-Hashing mit bcrypt (niemals Klartext)
• Parametrisierte Queries (niemals String-Konkatenation in SQL)
• JWT-Verifikations-Middleware auf geschützten Routen
• Eingabevalidierung auf allen Endpunkten (Typprüfung, Pflichtfelder, Längenlimits)
• CORS-Konfiguration, die Origins auf die Frontend-Domain beschränkt
• Rate Limiting auf Auth-Endpunkten gegen Brute Force
• Nutzer-gescopte Queries, die sicherstellen, dass Nutzer nur auf ihre eigenen Daten zugreifen

Das sind keine optionalen Add-ons, die Sie aktivieren. Sie sind Teil des Standard-Outputs, weil ich glaube, dass generierter Code standardmäßig sicher sein sollte.

Wann ist automatische Backend-Generierung die richtige Wahl?

Sie funktioniert am besten für standardmäßige datengetriebene Anwendungen: Aufgabenmanager, CRM-Tools, Inventarsysteme, Blogs, E-Commerce-Shops, Buchungsplattformen, Dashboards. Diese folgen Mustern, die die KI-Modelle gut beherrschen, und der generierte Code ist sauber, lesbar und wartbar.

Weniger geeignet ist sie für Anwendungen mit exotischen Anforderungen: Echtzeit-Kollaboration mit Operational Transforms, komplexe Finanzberechnungen oder Integration mit obskuren Drittanbieter-APIs. Generieren Sie dafür die Standardteile mit VULK und implementieren Sie die Spezialteile manuell.

Jede generierte Datei ist lesbar und modifizierbar. Keine vor Ihnen versteckte proprietäre Runtime, kein Framework-Lock-in auf dem Code, gegen den Sie schreiben. Wenn Sie dem generierten Backend entwachsen, exportieren Sie den Quellcode und refaktorieren ihn wie jede andere Anwendung.

Das ist das Prinzip, um das ich baue: VULK soll Ihre Entwicklung beschleunigen, nicht Sie in einem ummauerten Garten einsperren.