InCrowd

Il problema

Fra un cittadino che ha un’idea per la propria città e l’amministrazione che potrebbe realizzarla di solito non c’è quasi niente: un modulo, una PEC, al massimo un post su un gruppo Facebook. Le idee buone si perdono perché non esiste un posto dove si vede quante persone le condividono.

Il sistema

InCrowd è una piattaforma dove cittadini ed enti pubblicano proposte — titolo, descrizione, immagini, categoria, luogo, tempi previsti — e la comunità le sostiene con l’hype, una forma di appoggio pubblico che rende visibile quanto seguito ha davvero un’idea. Sopra c’è un livello di moderazione professionale che filtra i contenuti prima che diventino pubblici.

Il sistema distingue quattro ruoli con permessi diversi: cittadino privato, ente, moderatore e amministratore, ognuno con la propria interfaccia. Ci sono commenti moderati, un sistema di follow fra utenti e dashboard con statistiche per chi gestisce la piattaforma.

È il progetto del corso di Ingegneria del Software all’Università di Trento, sviluppato in squadra.

Cosa ho fatto io

È un progetto di squadra e non l’ho scritto da solo: diverse parti sono di altri membri del team, e molto è nato lavorando in coppia. Il mio contributo si concentra su tre fronti.

L’interfaccia. Mi sono occupato dello studio e della realizzazione delle schermate: come si muove un utente fra proposta, sostegno e commento, cosa vede un ente rispetto a un cittadino, e come si presenta l’hype in modo che si capisca al primo sguardo quanto seguito ha un’idea. Con quattro ruoli e permessi diversi, buona parte del lavoro è stata decidere cosa mostrare a chi.

Prima delle schermate è venuto il sistema di design, che trovi nel file Figma: le varianti del logo e una palette costruita a partire dal contrasto, con un colore principale, uno secondario e una coppia sfondo-testo scelta per restare leggibile anche in negativo. Averlo definito prima ha significato non dover discutere ogni bottone durante lo sviluppo.

Le fondamenta. Ho fatto l’impostazione iniziale del progetto: la struttura di backend e frontend, i modelli Mongoose e i tipi TypeScript condivisi fra le due parti, il setup di Vue e le prime API di gestione utente — lettura e registrazione. È il lavoro che decide la forma dei dati per tutto quello che viene dopo, e infatti il modello di allora è rimasto.

La documentazione delle API. Più avanti ho riscritto e ristrutturato da capo la specifica OpenAPI 3.0: definizione di tutti gli endpoint, flussi di autenticazione, ruoli utente, stati delle proposte, risposte di errore, schemi ed esempi di richiesta e risposta. Da elenco parziale è diventata una descrizione completa della piattaforma.

Lo stack

Backend in Node.js con Express e TypeScript, dati su MongoDB con Mongoose. Autenticazione con JWT e login Google via OAuth, password con bcrypt, controllo dei ruoli su ogni rotta. Frontend in Vue 3 con Composition API, Pinia per lo stato e Vite come build tool. Test con Jest su un MongoDB in memoria, eseguiti automaticamente a ogni commit da GitHub Actions. Entrambe le parti hanno un Dockerfile multi-stage su Alpine.

Cosa ne ho tratto

Che in un progetto a più mani i tipi condivisi valgono più di qualsiasi riunione: finché il modello dei dati è esplicito e sta in un posto solo, due persone possono lavorare sulle due metà senza parlarsi ogni mezz’ora. E che scrivere la documentazione di API che non hai scritto tu è il modo più rapido per scoprire dove il sistema è incoerente.