Un posto solo dove si vede chi gioca e quando
Nel padel il problema non è prenotare un campo: è trovare le persone con cui giocare. Le partite si formano e si disfano nel giro di un'ora, e ogni informazione vecchia di dieci minuti è una partita persa.
Risultati misurati
3
piattaforme dallo stesso progetto
SSE
aggiornamenti spinti dal server
0
servizi esterni per il tempo reale
Stripe
portafoglio e pagamenti
01 — Contesto
Informazioni che invecchiano in pochi minuti
Un posto libero in una partita vale finché qualcuno non lo prende. Se l'elenco si aggiorna solo quando l'utente ricarica, due persone prenotano lo stesso posto e qualcuno resta fuori — con una telefonata di scuse da fare.
La soluzione più comune è aggiungere un servizio esterno per il tempo reale. Funziona, ma aggiunge un fornitore, un costo e un altro pezzo che può rompersi.
02 — Approccio
Il tempo reale ce l'ha già il database
Gli aggiornamenti passano da PostgreSQL: quando un dato cambia, il database avvisa l'applicazione con `LISTEN`/`NOTIFY`, e l'applicazione lo spinge ai browser collegati con un flusso di eventi. Nessun servizio in più, nessuna coda esterna.
È una scelta che funziona bene alla scala di un circolo o di una rete di circoli: meno pezzi da tenere in piedi, e il dato in tempo reale nasce dalla stessa fonte che lo conserva.
03 — Soluzione
Cosa comprende
Campi e prenotazioni
Disponibilità, fasce orarie e prenotazione, con lo stato che si aggiorna da solo.
Partite aperte
Chi cerca giocatori pubblica la partita, chi cerca una partita la trova e si aggiunge.
Portafoglio
Credito e pagamenti gestiti con Stripe, per chiudere la prenotazione senza contanti.
Accesso e archiviazione
Autenticazione ospitata in proprio e archiviazione dei file su storage a oggetti.
04 — Dentro il codice
Un progetto solo che produce anche le app native
Quattrocento sorgenti TypeScript per il web, trentuno migrazioni di database, e accanto una cartella `native` con il codice Swift e Kotlin: le app per iOS e Android nascono dallo stesso progetto e parlano con la stessa API, invece di essere due lavori separati da tenere allineati a mano.
Le migrazioni numerate sono il registro di come la struttura dei dati è cambiata nel tempo: trentuno passaggi, ognuno reversibile. Su una piattaforma di prenotazioni, dove i dati storici delle partite servono per le statistiche, poter far evolvere il database senza perdere niente è un requisito, non un lusso.
C'è anche una cartella `design` con il sistema visivo e una `vision` con la direzione del prodotto: il progetto è scritto per essere ripreso, non solo per funzionare.
05 — Risultato
Meno pezzi, meno cose che si rompono
La piattaforma tiene insieme campi, partite e pagamenti su un impianto snello: un database che fa anche da canale per il tempo reale, autenticazione ospitata in proprio e nessun servizio di terze parti per gli aggiornamenti. Le app per iOS e Android nascono dallo stesso progetto.
