La migration m28 toglie i due job pg_cron che generavano il promemoria prima di ogni evento. Funzione, tipi, registro e notifiche già generate restano. Migration applicata in produzione. Nuovo test sui job non più pianificati; documentati DD-043, modulo notifiche, DATABASE, ROADMAP, WORKER_EMAIL e changelog. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2.2 KiB
2.2 KiB
Efficienza cloud
Regola di progetto: CrAPP gira su un piano cloud minimo (Supabase + Vercel) per ~17 utenti. Query, traffico e invocazioni vanno tenuti al minimo per costruzione, non ottimizzati dopo.
Regole da rispettare
- Niente polling: mai
refetchIntervalverso il database. Per sincronizzare più schede aperte si usanoBroadcastChannelo gli eventi distorage. - Cache lunga e passiva: i default del
QueryClientstanno insrc/router.tsx(staleTime5 min,gcTime30 min,refetchOnWindowFocus/Mount/Reconnectdisattivati,retry: 1). Non alzare la frequenza di refetch modulo per modulo. - Dopo una mutazione si aggiorna la cache con
setQueryData, non coninvalidateQueries: invalidare costa una rilettura. Unica eccezione:src/lib/scout-live.ts, dove il lock di sessione può essere stato preso da un altro dispositivo e la riga scritta non basta a sapere chi ha vinto. - Scout Live: scrive solo chi sta segnando; gli altri leggono dati già salvati.
- Write once, read many: statistiche, badge e classifiche si calcolano una volta e non
si ricalcolano a ogni apertura di pagina. I badge restano calcolati a runtime dai dati già
in cache, senza query aggiuntive (DD-007):
src/lib/rosa.tsaggrega ciò che è già stato letto. - Push solo per eventi importanti: convocazioni, turno palloni, esito finale.
- Niente funzionalità pesanti: foto, video, chat.
- Indici sui campi usati per filtri e relazioni in ogni nuova migration.
Obiettivi non ancora attuati
Questi punti sono stati definiti come direzione, ma non sono implementati: non descrivono il comportamento attuale.
- Dati CSI: sincronizzazione periodica server-side salvata su una tabella locale, con
l'app che legge solo dal database interno. Oggi la lettura è live dal portale a ogni
richiesta, tramite
/api/public/csi(vedi modules/collegamento-csi.md). - Aggregati persistiti: uno schema con
statistiche_aggregateeclassifica_csiè stato ipotizzato ma non esiste; nessuna di quelle tabelle è insupabase/migrations/. Va valutato con una decisione dedicata, perché tocca DD-007 (badge e statistiche calcolati a runtime).