Piattaforma
Backend: una base Supabase per una delivery software AI seria
Autenticazione, un vero database Postgres, archiviazione file e sicurezza a livello di riga arrivano con la tua app. Non come un progetto separato che devi collegare tu.
Il backend di Ciao è basato su Supabase: autenticazione, un database Postgres, archiviazione file, sicurezza a livello di riga e API generate insieme alla tua applicazione. A differenza degli app builder basati su fogli di calcolo, Ciao dà a ogni progetto un vero database relazionale con regole di accesso applicate dal database stesso. Infrastruttura standard che i tuoi ingegneri possono ispezionare e interrogare, e che possiedi insieme al resto del codice.
Pubblicato 2026-07-03 · Ultimo aggiornamento 2026-07-03
Le app reali hanno bisogno di un vero livello dati
Ogni applicazione seria è un database che indossa un'interfaccia utente. Il livello dati è anche dove gli app builder di solito prendono scorciatoie: fogli di calcolo come archiviazione, login incollato sopra, permessi come una speranza. Funziona nella demo, e poi si presenta un secondo team, clienti reali o un revisore.
Ciao dà a ogni applicazione un backend basato su Supabase: autenticazione, un database Postgres, archiviazione file, sicurezza a livello di riga e API. Generate insieme all'applicazione ed evolvono con essa. È l'infrastruttura che gli ingegneri sceglierebbero deliberatamente, che arriva senza la configurazione. E poiché arriva con l'applicazione, il modello di dati e l'interfaccia non si allontanano mai l'uno dall'altra, uno descrive l'altro.
Come si costruisce il backend
Il backend viene generato insieme all'applicazione e cresce attraverso lo stesso ciclo.
1. Descrivi i dati in linguaggio semplice
"I clienti hanno abbonamenti; le fatture appartengono ai clienti" diventa uno schema relazionale in Postgres, con tipi e relazioni appropriati.
2. L'autenticazione è collegata
Login, sessioni e gestione utenti esistono fin dall'inizio, perché l'autenticazione è la base su cui si costruisce ogni regola di accesso.
3. La sicurezza a livello di riga applica chi vede cosa
Le regole di accesso vivono nel database stesso: le query di un utente possono toccare solo le righe che la policy consente, anche se un bug si insinua nel codice dell'applicazione.
4. L'archiviazione gestisce i file
Upload, documenti e immagini trovano una casa con le stesse regole di accesso applicate. Non un bucket pubblico che qualcuno intendeva bloccare più tardi.
5. Le API espongono i dati
Gli endpoint generati permettono alla tua applicazione, e alle tue integrazioni, di lavorare con i dati in modo controllato e coerente.
6. Lo schema evolve sotto governance
Le modifiche arrivano come migrazioni su branch, tramite revisione e gate QA, così il livello dati cresce insieme al prodotto invece di ostacolarlo.
Perché è importante
La sicurezza a livello di riga è il dettaglio su cui vale la pena soffermarsi. I controlli di permesso a livello applicativo falliscono in modo aperto: una condizione dimenticata e i dati trapelano. La sicurezza a livello di riga fallisce in modo chiuso. Il database rifiuta ciò che la policy non consente. Il livello Security di Ciao sonda poi quei confini contro l'applicazione live, così "i permessi funzionano" viene testato, non presunto.
E poiché è Supabase e Postgres, infrastruttura standard, ampiamente utilizzata, niente nel tuo livello dati è proprietario. Gli ingegneri possono interrogarlo direttamente, e se esporti l'applicazione, lo schema e il modello di dati vanno con te. Il 100% di proprietà include il backend.
Il backend è anche dove lo sviluppo assistito da AI ha più bisogno di disciplina, perché i dati sopravvivono alle funzionalità. Le schermate vengono ricostruite; gli schemi si accumulano. Generare il livello dati tramite migrazioni governate, revisionate, testate, registrate, significa che il database a cinquecento modifiche da ora è ancora uno schema che qualcuno può leggere, non un sito archeologico con una pagina di login.
Chi lo usa
Un vero livello dati cambia su cosa può contare ogni ruolo.
- Non ingegneri. Ottengono un livello dati corretto, schema reale, permessi applicati, senza dover sapere cosa sia.
- Ingegneri. Postgres standard che possono ispezionare e interrogare, senza motore di archiviazione proprietario pronto a sorprenderli all'esportazione.
- Agenzie. Ogni build cliente poggia sulla stessa base affidabile invece di quello che il progetto della settimana ha improvvisato.
- Team regolamentati. Regole di accesso applicate, confini sondati e un registro di controllo. La storia del livello dati che la conformità chiede davvero.
Note di sicurezza e governance
- ✓ La sicurezza a livello di riga applica l'accesso al database, non solo nell'interfaccia.
- ✓ Le sonde di controllo degli accessi di Ciao Security esercitano quelle regole contro l'app live.
- ✓ Le modifiche allo schema vengono rilasciate come migrazioni tramite branch, revisione e gate QA.
- ✓ Il controllo degli accessi basato sui ruoli governa chi può modificare il livello dati.
- ✓ L'archiviazione file eredita le stesse regole di accesso dei dati a cui appartiene.
- ✓ Il codice del cliente non viene usato per addestrare i modelli; l'inferenza gira sotto contratti modello a conservazione zero.
- ✓ Lo schema è Postgres standard. Esportabile insieme alla tua applicazione in qualsiasi momento.
Cosa include ogni backend Ciao
Tutto in questa tabella viene fornito con ogni progetto. Niente di tutto ciò è un upgrade.
| Funzionalità | Cosa ottieni |
|---|---|
| Autenticazione | Login, sessioni e gestione utenti collegati all'app fin dall'inizio |
| Database Postgres | Uno schema relazionale reale generato da descrizioni in linguaggio semplice |
| Archiviazione file | Upload e documenti con le stesse regole di accesso applicate |
| Sicurezza a livello di riga | Accesso applicato dal database stesso, sondato contro l'app live |
| API | Endpoint generati per la tua applicazione e le sue integrazioni |
Domande frequenti
Il backend è vincolato a Ciao?
No. È basato su Supabase, Postgres standard, ed esportare la tua applicazione include lo schema e il modello di dati. Non c'è alcun motore di archiviazione proprietario tra te e i tuoi dati.
Cos'è la sicurezza a livello di riga in pratica?
Policy che vivono nel database e decidono, riga per riga, cosa ogni utente può leggere o scrivere. Se il codice applicativo ha un bug, il database rifiuta comunque le query che la policy non consente. I permessi falliscono in modo chiuso invece che aperto.
I nostri ingegneri possono lavorare direttamente con il database?
Sì. È Postgres standard, quindi possono ispezionarlo e interrogarlo con gli strumenti che già usano. Le modifiche allo schema continuano a fluire attraverso migrazioni governate, così l'accesso diretto non diventa una modifica non documentata.
Possiamo portare dati esistenti in un'app Ciao?
Sì. Descrivi la forma di ciò che hai e lo schema viene costruito per riceverlo, con le importazioni gestite come parte della build. Per migrazioni più grandi o più sensibili, parlane prima con il team.
Come interagisce il backend con i test di sicurezza?
Le sonde di controllo degli accessi tentano letture e scritture cross-confine contro l'applicazione live. Le policy di sicurezza a livello di riga vengono esercitate, non solo revisionate. I risultati alimentano la dashboard di sicurezza per la pubblicazione.
Pagine correlate
Costruisci il software che prima dovevi solo aspettare.
Blocco backend: autenticazione Supabase, Postgres, API | Ciao