// il problema
Tre tipi di utenti, un solo posto.
L'Accademia Campania organizza stage, gare e formazione per la danza sportiva e lavora con una rete di scuole affiliate. Serviva una piattaforma unica, non un semplice sito vetrina: la direzione deve creare e pubblicare gli eventi, i tecnici delle scuole devono poter iscrivere i propri atleti, e ogni atleta deve ritrovare eventi, gare e il proprio diario.
Il vincolo più delicato era la riservatezza: un tecnico vede solo i propri atleti, il listino è visibile solo alle strutture abilitate, e nessuno deve poter modificare importi o stato dei pagamenti dal proprio account.
// la soluzione
Sito pubblico più area riservata.
Un monorepo con una sola applicazione web: le pagine pubbliche raccontano l'accademia, l'area riservata cambia in base al ruolo di chi accede.
Gerarchia Admin → Tecnico → Atleta
La direzione approva le strutture. Il tecnico approvato invita i propri atleti con un link dedicato e li ritrova associati in automatico. Chi è in attesa di approvazione vede solo la pagina di attesa.
Eventi e prenotazioni
Stage e gare con pacchetti. Il tecnico seleziona più atleti insieme e vede il totale aggiornarsi in tempo reale; la direzione conferma i pagamenti e gestisce gli annullamenti.
Regole applicate dal database
La capienza non può scendere sotto i posti già prenotati, un evento con prenotazioni si annulla ma non si cancella, un evento senza pacchetti non si pubblica. Sono vincoli del database, non controlli del frontend.
Sicurezza verificata con test
Ogni tabella ha policy Row Level Security per anonimo, admin, tecnico e atleta. Le policy sono coperte da test pgTAP, in maggioranza negativi: verificano ciò che un ruolo non deve riuscire a fare.
Hero che avanza con lo scroll
Nella home il video della coppia avanza insieme allo scroll, con testo che si accende parola per parola e braci d'oro disegnate su canvas. Su telefono le sezioni orizzontali diventano scroll nativo.
Diario e storico dell'atleta
Ogni atleta ha lo storico di eventi e gare e un diario personale, visibile soltanto al proprio tecnico.
// stack tecnologico
// domande frequenti
In breve.
Di cosa si è occupato VMDProject?
Dell'intero progetto: architettura, schema del database e policy di sicurezza, interfaccia, animazioni, email transazionali, ambienti di staging e produzione e messa online.
Perché la sicurezza è nel database e non nel frontend?
Perché un controllo fatto solo nell'interfaccia si aggira chiamando direttamente le API. Con le policy Row Level Security è il database a rifiutare la richiesta, qualunque client la invii.
Com'è organizzato il rilascio?
Due ambienti separati, staging e produzione, ciascuno con il proprio database. Ogni modifica passa da typecheck, lint, build e test del database prima di arrivare in produzione; i flussi principali sono coperti da test end-to-end.