Die m77-Datenbank nutzen: Collections, Filter und Daten pro Nutzer

Meistens wirst du die Datenbank nie direkt anfassen – du beschreibst deine App, und builder77 schreibt den Code, der Daten speichert und liest. Wenn du aber weißt, wie sie funktioniert, schreibst du bessere Prompts, findest Fehler schneller und triffst gute Entscheidungen zum Datenschutz. Hier ist eine Tour durch m77.db.

Collections und Datensätze

Daten liegen in Collections – benannten Gruppen von Datensätzen wie tasks, bookings oder posts. Ein Schema musst du nicht definieren: Eine Collection entsteht, sobald du zum ersten Mal hineinschreibst, und jeder Datensatz ist ein einfaches Objekt mit den Feldern, die du ihm gibst.

const task = await m77.db.create('tasks', { title: 'Write launch post', done: false });
// -> { id, title, done, createdAt, updatedAt, ownerId }

builder77 fügt id, createdAt, updatedAt und ownerId automatisch hinzu. ownerId wird auf den angemeldeten App-Nutzer gesetzt, falls es einen gibt – das wird weiter unten bei den Berechtigungen wichtig.

Daten lesen: list, get und count

const open = await m77.db.list('tasks', {
  where: { done: false },   // exact-match filter
  sort: '-createdAt',       // '-' = descending
  limit: 50                 // up to 500
});

const one = await m77.db.get('tasks', id);          // record or null
const doneCount = await m77.db.count('tasks', { where: { done: true } });

where vergleicht Felder auf exakte Übereinstimmung, und das deckt die meisten Anforderungen einer App ab: Statusfilter, Kategorien, eine übergeordnete ID für verknüpfte Datensätze. Für eine Suche beim Tippen in einer überschaubaren Liste lädt man die Datensätze meist und filtert im Browser.

Aktualisieren und löschen

await m77.db.update('tasks', id, { done: true });   // shallow merge
await m77.db.remove('tasks', id);

update führt die übergebenen Felder mit dem bestehenden Datensatz zusammen, du musst also nur senden, was sich geändert hat.

Daten pro Nutzer mit mine: true

Für Apps, in denen jede Person ihre eigenen Daten hat – Tagebücher, Budgets, Gewohnheits-Tracker –, kombinierst du m77.auth mit der Option mine. Ist ein Nutzer angemeldet, liefert mine: true nur die Datensätze, die er selbst angelegt hat.

await m77.auth.signIn({ email, password });

const myEntries = await m77.db.list('entries', { mine: true, sort: '-createdAt' });

Eine zweite Schutzebene ist bereits eingebaut: Ein Datensatz, den ein angemeldeter Nutzer angelegt hat, kann nur von genau diesem Nutzer aktualisiert oder gelöscht werden. Selbst wenn jemand eine Anfrage von Hand zusammenbaut, lehnt die API Änderungen an fremden Datensätzen ab.

Öffentliche vs. private Daten: ein kurzer Leitfaden

• Öffentliche Inhalte (Speisekarten, Blogbeiträge, Produktlisten): Zum Lesen ist kein Login nötig. Lass builder77 Beispieldaten anlegen oder einen Admin-Bereich zur Verwaltung bauen, und bearbeite sie jederzeit im Tab „Daten“.
• Einsendungen (Kontaktformulare, Wartelisten, Buchungen): Jeder kann sie anlegen; du liest sie im Tab „Daten“.
• Persönliche Daten (Notizen, Gesundheitsprotokolle, Finanzen): Login voraussetzen und immer mit mine: true abfragen.

Eine Faustregel: Alles im Frontend-Code deiner App ist für Besucher sichtbar, und Listen ohne mine: true kann jeder lesen, der den Link zur App hat. Sind Daten persönlich, gehören sie hinter einen Login und mine. Ist die ganze App nur für dich oder dein Team, aktiviere in den Einstellungen Private App.

Der Tab „Daten“

Im Builder kannst du im Tab Daten alle Collections durchsuchen, Datensätze bearbeiten oder löschen, die Nutzer deiner App sehen und hochgeladene Dateien prüfen. So korrigierst du am schnellsten einen Tippfehler im Inhalt, räumst Testeinträge auf oder prüfst, ob ein Formular speichert, was es soll.

Dieselben Daten aus Flutter und anderen Clients

Das Web-SDK ist eine schlanke Hülle um eine REST-API, die auch Flutter-Exporte verwenden. Das heißt, jeder Client kann dieselben Collections lesen und beschreiben:

GET  /api/runtime/<projectId>/db/tasks?where={"done":false}&sort=-createdAt&limit=100
POST /api/runtime/<projectId>/db/tasks   { "data": { "title": "Hi" } }
Authorization: Bearer <appUserToken>   (optional, from /auth/signin)

Tokens von App-Nutzern gelten nur für ein einzelnes Projekt, ein Token aus einer App lässt sich also nicht bei einer anderen verwenden. Lese- und Schreibzugriffe auf die Datenbank verbrauchen keine Credits – bau deine App so datenintensiv, wie du willst.

Prompts für Daten

All das kannst du in ganz normaler Sprache steuern: „Speichere Ausgaben mit Betrag, Kategorie und Datum; jeder Nutzer sieht nur seine eigenen“ oder „Füge Buchungen ein Statusfeld und einen Filter für offene Buchungen hinzu“. Die KI kennt das SDK, meist genügt es also, das Datenmodell zu beschreiben.