Usare il database m77: collezioni, filtri e dati per utente

Il più delle volte non toccherai mai il database direttamente: descrivi la tua app e builder77 scrive il codice che salva e legge i dati. Ma sapere come funziona ti aiuta a scrivere prompt migliori, a fare debug più in fretta e a prendere buone decisioni sulla privacy. Ecco un giro di m77.db.

Collezioni e record

I dati vivono nelle collezioni — gruppi di record con un nome, come tasks, bookings o posts. Non c'è uno schema da definire: una collezione viene creata la prima volta che ci scrivi, e ogni record è un semplice oggetto con i campi che gli assegni.

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

builder77 aggiunge automaticamente id, createdAt, updatedAt e ownerId. ownerId viene impostato sull'utente dell'app che ha effettuato l'accesso, quando c'è, e questo diventa importante per i permessi, come vedremo più avanti.

Leggere i dati: list, get e 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 confronta i campi in modo esatto, e questo copre la maggior parte delle esigenze di un'app: filtri per stato, categorie, un ID padre per i record collegati. Per una ricerca mentre si digita su un elenco di dimensioni contenute, di solito si caricano i record e si filtra nel browser.

Aggiornare ed eliminare

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

update unisce i campi che passi al record esistente, quindi devi inviare solo ciò che è cambiato.

Dati per utente con mine: true

Per le app in cui ogni persona ha i propri dati — diari, budget, tracker di abitudini — combina m77.auth con l'opzione mine. Quando un utente ha effettuato l'accesso, mine: true restituisce solo i record che ha creato lui.

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

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

C'è anche un secondo livello di protezione integrato: un record creato da un utente autenticato può essere aggiornato o eliminato solo da quello stesso utente. Anche se qualcuno costruisce una richiesta a mano, l'API rifiuta le modifiche ai record che non gli appartengono.

Dati pubblici e privati: una guida rapida

• Contenuti pubblici (menu, articoli del blog, schede prodotto): non serve il login per leggerli. Chiedi a builder77 di inserire dati di esempio o di aggiungere una schermata di amministrazione per gestirli, e modificali quando vuoi nella scheda Dati.
• Invii (moduli di contatto, liste d'attesa, prenotazioni): chiunque può crearli; tu li leggi nella scheda Dati.
• Dati personali (note, registri sulla salute, finanze): richiedi il login e interroga sempre con mine: true.

Una regola pratica: tutto ciò che sta nel codice front-end della tua app è visibile ai visitatori, e gli elenchi senza mine: true possono essere letti da chiunque abbia il link dell'app. Se i dati sono personali, mettili dietro il login e mine. Se l'intera app è solo per te o per il tuo team, attiva App privata nelle Impostazioni.

La scheda Dati

Nel builder, la scheda Dati ti permette di sfogliare ogni collezione, modificare o eliminare record, vedere gli utenti della tua app e controllare i file caricati. È il modo più rapido per correggere un refuso nei contenuti, ripulire le voci di prova o verificare che un modulo salvi ciò che ti aspetti.

Gli stessi dati da Flutter e da altri client

L'SDK web è un sottile strato sopra un'API REST, la stessa usata dalle esportazioni Flutter. Questo significa che qualsiasi client può leggere e scrivere nelle stesse collezioni:

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)

I token degli utenti dell'app sono limitati a un singolo progetto, quindi un token di un'app non può essere usato su un'altra. Letture e scritture nel database non consumano crediti: crea un'app ricca di dati quanto vuoi.

Descrivere i dati nei prompt

Puoi guidare tutto questo con un linguaggio semplice: “salva le spese con importo, categoria e data; ogni utente vede solo le proprie”, oppure “aggiungi un campo stato alle prenotazioni e un filtro per quelle in attesa”. L'IA conosce l'SDK, quindi di solito basta descrivere il modello dei dati.