KI-App-Builder mit Supabase: Datenbank, Login, Dateien
KI-App-Builder mit Supabase: Datenbank, Login, Dateien
Ja, ein generiertes Projekt speichert echte Daten. Dafür steht Supabase als Anbindung bereit: Sie verbinden Ihr Supabase-Projekt, und ab da liegen Datensätze in Ihrer Datenbank, melden sich Nutzer über Ihre Anmeldung an und landen hochgeladene Dateien in Ihrem Speicher. Das Konto gehört Ihnen, nicht dem Builder.
Damit ist aus einer Website ein Produkt geworden. Der Unterschied ist größer, als er klingt, und dieser Text geht durch, was dabei entsteht, was Sie entscheiden müssen und was vor dem ersten echten Datensatz zu prüfen ist.
Was ändert eine Datenbank an einem Projekt?
Ohne Datenbank zeigt ein Projekt allen Besuchern dasselbe. Es ist eine Broschüre: gut für Vorstellung, Angebot und Kontaktaufnahme, und für viele Vorhaben völlig ausreichend.
Mit Datenbank merkt sich das Projekt etwas. Eine Anfrage bleibt erhalten, eine Buchung belegt einen Termin, ein Nutzer sieht seine eigenen Einträge und nicht die von jemand anderem. Ab diesem Moment gibt es Zustände, die sich ändern, und genau das macht den Unterschied zwischen einer Seite und einer Anwendung.
Die praktische Folge ist eine andere Denkweise beim Beschreiben. Für eine Broschüre beschreiben Sie Abschnitte, für eine Anwendung beschreiben Sie Rollen und Handlungen: Wer meldet sich an, was legt er an, wer darf es sehen. Wer diesen Satz vorab schreibt, spart mehrere Runden Nacharbeit. Der ausführliche Einstieg dazu steht in Kann KI eine Datenbank-Anwendung bauen.
Was bekommt das Projekt durch die Anbindung?
Supabase bringt drei Bausteine mit, und die meisten Projekte brauchen alle drei.
| Baustein | Was er im Projekt bewirkt | Typisches Beispiel |
|---|---|---|
| Datenbank | Speichert Datensätze dauerhaft | Anfragen, Buchungen, Artikel, Aufgaben |
| Anmeldung | Erkennt wiederkehrende Nutzer | Kundenkonto, interner Bereich für Mitarbeiter |
| Dateiablage | Nimmt Uploads entgegen | Fotos, Belege, Grundrisse, Verträge |
Der zweite Baustein ist der, der am häufigsten unterschätzt wird. Sobald es eine Anmeldung gibt, gibt es auch Fragen nach Passwort vergessen, nach dem ersten Zugang für neue Mitarbeiter und danach, was jemand nach dem Ausscheiden noch sehen darf. Das ist keine technische Schwierigkeit, sondern eine Entscheidung, die Sie treffen und beschreiben müssen. Wie weit die Anmeldung aus dem Builder trägt, behandelt Kann KI eine Anmeldung bauen.
Der dritte Baustein hat eine Eigenschaft, die man erst später spürt: Dateien wachsen. Ein Handwerksbetrieb, der Baustellenfotos hochlädt, sammelt in einem Jahr mehr Daten als in der gesamten Datenbank. Legen Sie früh fest, was hochgeladen werden darf und was nicht.
Wie beschreibe ich ein Projekt, damit die Datenstruktur passt?
Der Unterschied zwischen einem brauchbaren und einem unbrauchbaren Ergebnis liegt fast immer in der Beschreibung, nicht im Builder.
Nennen Sie die Rolle. „Mitarbeiter melden sich an" ist etwas anderes als „Kunden melden sich an", und wieder etwas anderes als beides gleichzeitig mit unterschiedlichen Ansichten.
Nennen Sie die Sichtbarkeit. Der Satzteil „jeder sieht nur seine eigenen" ist der wichtigste in der ganzen Beschreibung. Ohne ihn entsteht mit einiger Wahrscheinlichkeit eine gemeinsame Liste, die alle sehen, und das fällt erst beim zweiten Nutzer auf.
Nennen Sie die Handlungen in der richtigen Reihenfolge. „Kunde wählt einen Termin, Termin ist danach für andere belegt, Inhaberin sieht alle Termine des Tages" beschreibt drei Zustände und ergibt eine sinnvolle Struktur.
Und nennen Sie Ihre Felder. Wer eine Anfrage mit Kundennummer, Objektadresse und Wunschtermin braucht, sollte das schreiben. Ein Modell rät sonst plausibel, aber nicht nach Ihren Formularen.
Wem gehören die Daten?
Die Antwort ist der eigentliche Grund für diese Anbindung. Die Datenbank ist ein Supabase-Projekt in Ihrem Konto. Sie öffnen dessen Oberfläche, sehen Ihre Tabellen, exportieren Inhalte und nehmen sie mit, ganz gleich, ob Sie Zugo je wieder öffnen.
Zusammen mit den anderen Anbindungen ergibt das eine saubere Aufteilung. Der Code liegt nach dem Export in Ihrem Repository, die Auslieferung läuft über Ihr Hosting-Konto, die Daten liegen in Ihrer Datenbank. Kein Teil davon hängt an einem Abonnement, auch nicht an dem bei Zugo. Die Code-Hälfte ist in KI-App-Builder mit GitHub beschrieben.
Für ein Unternehmen ist das mehr als eine Grundsatzfrage. Es ist die Antwort auf die Prüfung durch einen größeren Kunden, auf den Wechsel eines Dienstleisters und auf die schlichte Frage, was passiert, wenn jemand die Rechnung übersieht.
Was ist mit Datenschutz und Serverstandort?
Sobald personenbezogene Daten gespeichert werden, ist das eine datenschutzrechtliche Angelegenheit und keine reine Technikfrage. Drei Punkte gehören dabei früh geklärt.
Erstens die Region. Bei der Anlage eines Supabase-Projekts wird der Standort gewählt, und diese Entscheidung treffen Sie dort, nicht im Builder. Nachträglich zu wechseln ist unangenehmer, als es vorher richtig zu machen.
Zweitens die Verträge. Für die Verarbeitung durch einen Dienstleister braucht es die entsprechende vertragliche Grundlage, und in der Datenschutzerklärung Ihres Projekts muss stehen, welche Dienste beteiligt sind.
Drittens die Datensparsamkeit. Die wirksamste Maßnahme ist, weniger zu speichern. Ein Kontaktformular braucht selten ein Geburtsdatum, und ein Feld, das es nicht gibt, muss weder geschützt noch gelöscht werden. Diese Absätze sind eine Einordnung aus der Praxis und keine Rechtsberatung.
Warum sollte ich die Zugriffsregeln vor dem Start prüfen?
Weil das der einzige Fehler in dieser Liste ist, den man von außen nicht sieht. Eine Anwendung, in der jeder alles lesen kann, sieht genauso aus wie eine, in der die Regeln stimmen. Der Unterschied fällt erst auf, wenn ihn jemand ausnutzt.
Der Test dafür ist einfach und dauert Minuten. Legen Sie zwei Testkonten an, tragen Sie mit beiden je einen Datensatz ein und sehen Sie nach, ob Konto A den Eintrag von Konto B sieht. Genau dieser Durchgang findet die häufigste Schwachstelle solcher Projekte.
Ergänzend lohnt ein Blick in die Zugriffsregeln der Tabellen im Supabase-Konto, bevor die ersten echten Kundendaten hineingehen. Das ist ein Vorteil dieser Anbindung: Die Regeln sind einsehbar und änderbar, und zwar unabhängig davon, wie das Projekt entstanden ist. Für heiklere Daten holen Sie sich zusätzlich eine fachliche Prüfung, denn diese Frage entscheidet sich nicht im Design.
Was kostet das im Builder?
Die Anbindung verbraucht keine Credits, und Supabase rechnet sein eigenes Kontingent nach eigenen Bedingungen ab. Credits gehen ausschließlich für Generierung weg.
| Aktion | Credits | Im Hi-Fi-Modus |
|---|---|---|
| Änderung an einem Projekt | 3 | 6 |
| Frischer Build | 6 | 12 |
| Mehrseitige Plattform | 12 für die ersten drei Seiten, dann 3 je weiterer Seite | doppelt |
Free gibt 5 Credits, Pro kostet 25 $ im Monat und enthält 200 Credits, Business kostet 99 $ im Monat und enthält 800. Zweihundert Credits sind rund 16 mehrseitige Plattformen oder 33 Builds oder 66 Änderungen, jeweils für eine Art von Aktion gerechnet. Abgerechnet wird in US-Dollar, und 5 Credits sind weniger als die 6, die ein einzelner Build kostet.
Für Projekte mit Datenbank ist die Zeile mit der mehrseitigen Plattform die realistische: Anmeldung, Übersicht, Detailansicht und Verwaltung sind selten eine einzige Seite. Rechnen Sie mit einem Build und mehreren Änderungen, bis die Struktur zu Ihren Abläufen passt.
Was leistet die Anbindung nicht?
Drei Grenzen, die vor den ersten echten Daten klar sein sollten.
Eine erzeugte Struktur ist ein guter Entwurf und kein endgültiges Datenmodell. Sehen Sie sich die Tabellen an, bevor sie Monate an Einträgen angesammelt haben. Eine zentrale Tabelle in Woche eins umzubenennen kostet nichts, im Monat sechs kostet es einen Abend.
Der Builder ersetzt bei einem komplexen Produkt kein Entwicklungsteam. Auswertungen über große Datenmengen, Verknüpfungen mit einem Warenwirtschaftssystem oder feingliedrige Rechte innerhalb einer Organisation sind Ingenieursarbeit. Sehr spezifische Fachlogik entsteht über mehrere Änderungen, nicht über einen einzigen Satz.
Und die Prüfung vor der Auslieferung sagt weniger, als viele annehmen. Jeder Build läuft in einer Sandbox, und was nicht öffnet, wird nicht ausgeliefert. Damit bekommen Sie nichts Kaputtes. Ob Ihre Zugriffsregeln stimmen, sagt Ihnen dieser Test nicht.
Welche Reihenfolge ist sinnvoll?
Beschreiben, bauen, mit zwei Testkonten prüfen, Zugriffsregeln ansehen, und erst dann echte Kundendaten hineinlassen. Diese vier Schritte kosten einen Abend und ersparen die unangenehmste Sorte von Überraschung.
Fangen Sie klein an: eine Rolle, eine Tabelle, eine Liste. Erweitern lässt sich das mit Änderungen zu je 3 Credits, und jede Erweiterung ist einfacher zu beurteilen als ein großer Wurf. Eine einfache Anwendung steht in etwa einer Minute, eine mehrseitige Plattform in einigen Minuten, und es gibt 25 Vorlagen, davon 5 für Spiele, als Ausgangspunkt. Ausprobieren können Sie das auf zugo.dev.