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

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

  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).
  • 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).