Da oggi le risposte ai link di presenza arrivano in dashboard senza dover ricaricare la pagina. Sembra una feature minore, e in effetti la riga di rilascio nel changelog e' di una sola parola: "Realtime". Eppure cambia il modo di gestire l'ora prima della partita per chiunque pubblichi sessioni in ElevenBase.
Il prima
Fino alla settimana scorsa, dopo aver pubblicato una sessione e copiato il link in chat, il flusso del founder era questo: aprivi la sessione in dashboard, vedevi quanti avevano risposto in quel momento, e per sapere se ne erano arrivati di nuovi dovevi ricaricare. Funzionava, ma era stancante.
Lo stancante non era il click in se'. Era il fatto che, nell'ora cruciale prima del fischio d'inizio, il numero che conta di piu' e' quello che racconta quante persone in piu' hanno appena confermato. Se quel numero te lo devi calcolare a mente confrontando la pagina di adesso con quella di tre minuti fa, finisci per tenere il telefono in mano e premere F5 ogni 30 secondi.
Cosa e' cambiato
Da oggi, quando apri una sessione attiva, il pannello risposte si iscrive automaticamente a un canale Realtime di Supabase. Realtime e' una feature di Supabase basata su Postgres logical replication: il database emette un evento ogni volta che una riga della tabella session_responses viene inserita, aggiornata o cancellata, e il frontend riceve quell'evento via WebSocket entro qualche centinaio di millisecondi.
Per il founder questo significa una cosa sola: appena un giocatore tocca "Presente", "Ritardo" o "Assente" dal link pubblico, il suo nome compare nella sezione corrispondente della tua dashboard senza che tu debba fare nulla.
Sotto il cofano
Il client React si iscrive al canale Realtime con filtro su session_id. Il filtro lato server garantisce che il client riceva solo eventi per la sessione che sta guardando. Le RLS policy di Postgres assicurano che il client autenticato veda solo le sessioni del proprio team.
Quando il browser riceve l'evento, React Query invalida la cache della query session_responses per quella sessione. Il rendering React si fa carico di animare l'inserimento del nuovo nome nella sezione giusta. Tutta la pipeline, dal tap del giocatore al rendering nella dashboard del founder, sta sotto i 500 ms nelle condizioni di rete tipiche italiane.
Edge case: la connessione che si addormenta
Una WebSocket non e' una connessione magica: se il browser va in background, se il computer va in sleep, o se il network cellulare cambia da Wi-Fi a 4G, la connessione puo' chiudersi senza che il client se ne accorga subito. Per coprire questo caso, il client di Realtime fa un ping ogni 30 secondi e, se non riceve risposta, riconnette in automatico.
Cosa cambia nella pratica
L'esempio reale e' un episodio raccontato dallo staff di Ca De Rissi SG il giorno del rilascio interno. Sessione pubblicata alle 18:00, partita prevista alle 21:30. Il founder ha aperto la dashboard alle 20:00 mentre cucinava — l'ha appoggiata su un leggio in cucina. Pochi minuti dopo arriva la prima conferma; poco dopo qualcuno cambia idea da "ritardo" a "presente"; alle 20:49 un giocatore mette "out" per imprevisto lavoro. Alle 21:00, dieci minuti prima dell'inizio, sapeva che erano in undici e ha potuto scrivere in chat un solo messaggio per chi era in ritardo.
E' un risparmio piccolo, una decina di interazioni nell'arco di un'ora. Ma e' esattamente il tipo di risparmio che si accumula su una stagione di 30 partite e che, soprattutto, libera attenzione mentale per le cose che davvero richiedono di essere pensate.
Cosa serve fare
Niente. Realtime e' attivo per default su tutti i team a partire da oggi. Se per qualche motivo la connessione non riesce ad aprirsi, l'app fa fallback automatico al polling ogni 30 secondi: vedrai i nomi arrivare con qualche secondo di ritardo invece che istantaneamente, ma non perderai nulla.