davideandClaude Opus 5.5
61d4dacb3a
Scarica schema e dati del database (public e auth) e i file dei bucket storage, così si può ripartire se si perdono Supabase o Vercel. I dati generati restano fuori da git perché contengono dati personali reali. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
3.4 KiB
3.4 KiB
Portabilità di CrAPP
Regola di progetto: l'app deve poter girare su un normale server Node.js + PostgreSQL, senza dipendere da servizi esclusivi di Lovable Cloud.
Stato attuale
| Componente | Portabile? | Note |
|---|---|---|
| Frontend (React + TanStack Start/Router) | Sì | Build Vite standard, deploy su qualsiasi host Node. |
Server functions / route API (src/routes/api/*) |
Sì | API HTTP standard, nessuna edge function proprietaria. |
| Database | Sì | PostgreSQL puro; lo schema sta nelle migrazioni SQL. |
Client dati (@supabase/supabase-js) |
Sì | Supabase è open source e self-hostable; in alternativa si sostituisce il solo livello dati (src/lib/*.ts). |
Web Push (src/lib/webpush.server.ts) |
Sì | VAPID implementato con Web Crypto, disponibile in Node 18+. |
| Auth | Sì | GoTrue self-hosted oppure qualsiasi provider OIDC. |
@lovable.dev/vite-tanstack-config |
Solo build | Preset Vite; sostituibile con una config Vite/TanStack esplicita. |
Regole da rispettare nelle prossime modifiche
- Nessun accesso al database dai componenti: solo attraverso i moduli in
src/lib/*.ts(palloni.ts,mvp-voti.ts, ...), così il backend è sostituibile in un solo punto. - Nessun uso di funzionalità proprietarie (edge functions Lovable, auth Lovable come unico metodo di login, storage proprietario).
- Configurazione solo via variabili d'ambiente standard
(
DATABASE_URL/SUPABASE_URL+ chiavi,VAPID_*), mai valori hardcoded. - SQL standard PostgreSQL nelle migrazioni: niente estensioni esclusive del provider.
- Job pianificati richiamabili via semplice HTTP POST (es.
/api/public/promemoria-palloni), così funzionano con cron di sistema, pg_cron o qualsiasi scheduler.
Backup e disaster recovery
Lo script backups/backup.sh scarica su un host locale schema e
dati del database (public e auth), utenti Supabase Auth e file dei bucket storage, in
modo da poter ripartire in fretta se il progetto Supabase (o Vercel) venisse perso.
Uso, contenuto del backup e procedura di ripristino sono descritti in
backups/README.md. Non ancora automatizzato: l'export delle
variabili d'ambiente Vercel (richiede login interattivo).
Migrazione su server proprio (sintesi)
bun run build(onpm run build) → avvio del server Node generato.- PostgreSQL proprio + applicazione delle migrazioni in
supabase/migrations. - Impostare le variabili d'ambiente (database, chiavi API,
VAPID_*). - Se non si usa Supabase self-hosted: riscrivere solo i moduli dati in
src/lib/con un client Postgres (es.postgres/pg) dentro server functions.