Salta al contenuto principale
Portfolio

Sviluppo

Staffing eventi — web-app interna

Il giro di messaggi per coprire i turni di un evento diventa un flusso unico, dove ognuno vede solo il pezzo che lo riguarda.

Ruolo
Progettazione e sviluppo full-stack
Committente
Space42 Europe · strumento interno
Periodo
2026
Stato
In uso interno — non pubblico

Il problema

Coprire i turni di un evento passava da email e messaggi: chi è disponibile, chi è già assegnato, chi ha lavorato l’ultima volta. Le informazioni esistevano, ma sparse fra le conversazioni di chi le aveva scritte.

Senza uno storico, la distribuzione dei turni finiva per dipendere da chi si ricordava cosa — e questo è un problema di equità prima ancora che di organizzazione.

Il risultato

Un percorso unico: si pubblica l’evento, i collaboratori dichiarano la disponibilità, si assegna, si conferma, resta lo storico.

Le assegnazioni tengono conto delle competenze e della disponibilità dichiarata, e la distribuzione segue un criterio di equità esplicito invece che la memoria di chi assegna.

  1. Evento
  2. Adesioni
  3. Assegnazione
  4. Conferma
  5. Storico
Il percorso di un evento: ogni passaggio è uno stato, e nessuno salta il precedente.

Com’è fatto

Monorepo pnpm: una SPA React 19 su Vite e un backend Directus 11, più i moduli condivisi fra i due.

La SPA non parla con il CMS da un dominio diverso: lo raggiunge su un path della stessa origine, con un proxy in sviluppo e un reverse proxy in produzione. La sessione vive così in un cookie httpOnly, che il JavaScript della pagina non può leggere.

Frontend
React 19ViteTypeScript
Backend
Directus 11PostgreSQL
Struttura
Monorepo pnpmModuli condivisi

Decisioni

Ogni scelta qui sotto ha avuto un prezzo. Elencarle senza dire cosa costano le farebbe sembrare gratuite, e nessuna lo è stata.

  1. Sessione in cookie httpOnly, non token nel browser

    Servire l’API sotto la stessa origine dell’applicazione permette di usare un cookie che lo script di pagina non può leggere. Un token in localStorage è a portata di qualsiasi codice giri nella pagina.

    Cosa è costato In produzione serve un reverse proxy: non basta puntare il frontend all’indirizzo del CMS.

  2. L’equità è una regola scritta

    Il criterio con cui i turni si distribuiscono sta nel codice, quindi si può leggere, discutere e correggere. Finché era nella testa di chi assegnava, non era né verificabile né contestabile.

    Cosa è costato Una regola esplicita è anche una regola che qualcuno può trovare ingiusta. È il punto: prima non c’era niente da contestare.

  3. Directus invece di un backend su misura

    Autenticazione, ruoli, permessi e CRUD arrivano dalla piattaforma. Il codice scritto a mano è quello che riguarda il dominio — eventi, adesioni, assegnazioni — e nient’altro.

    Cosa è costato Ci si adatta al modello della piattaforma, e alcune cose si fanno come vuole lei.