davideandClaude Sonnet 5.5
e9013b703b
m23: un registro (promemoria_eventi_generati) ricorda i promemoria a 24 e 3 ore già generati, così eliminare la notifica non li fa rigenerare dal cron né riaccodare la mail a ogni giro. m24: la push dei promemoria, che nascono nel database, la manda il worker mailer/ con lo stesso modulo dell'app (coda notifiche_push_coda, esiti, backoff, iscrizioni scadute eliminate, push scartate oltre 3 ore). Il sondaggio pre-partita scrive anche notifiche_utente (tipo sondaggio_cacche): compare in-app e arriva per email. L'immagine del worker si costruisce dalla radice del repository per includere src/lib/webpush.server.ts. Test: 9 di integrazione per m23, 17 per la coda push, 6 per la route del sondaggio, nuovi casi unitari sul worker; prova end-to-end con un servizio push finto. Documentazione e catalogo delle notifiche aggiornati. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
4.2 KiB
4.2 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. |
Worker email (mailer/) |
Sì | Container su qualsiasi host con Docker; parla solo con Supabase (RPC), con un server SMTP a scelta e con i servizi push dei browser (WORKER_EMAIL.md). |
@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.