Files
CRAPP/docs/EFFICIENZA_CLOUD.md
T
davideandClaude Sonnet 5.5 e822e4574b Rimuove il promemoria evento a 24 e 3 ore (DD-043)
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>
2026-10-01 14:49:30 +02:00

38 lines
2.2 KiB
Markdown

# 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
1. **Niente polling**: mai `refetchInterval` verso il database. Per sincronizzare più schede
aperte si usano `BroadcastChannel` o gli eventi di `storage`.
2. **Cache lunga e passiva**: i default del `QueryClient` stanno in `src/router.tsx`
(`staleTime` 5 min, `gcTime` 30 min, `refetchOnWindowFocus/Mount/Reconnect` disattivati,
`retry: 1`). Non alzare la frequenza di refetch modulo per modulo.
3. **Dopo una mutazione si aggiorna la cache con `setQueryData`**, non con
`invalidateQueries`: 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.
4. **Scout Live**: scrive solo chi sta segnando; gli altri leggono dati già salvati.
5. **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.ts` aggrega ciò che è già stato
letto.
6. **Push solo per eventi importanti**: convocazioni, turno
palloni, esito finale.
7. **Niente funzionalità pesanti**: foto, video, chat.
8. **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](modules/collegamento-csi.md)).
- **Aggregati persistiti**: uno schema con `statistiche_aggregate` e `classifica_csi` è stato
ipotizzato ma non esiste; nessuna di quelle tabelle è in `supabase/migrations/`. Va valutato
con una decisione dedicata, perché tocca DD-007 (badge e statistiche calcolati a runtime).