Vai al contenuto

Monitoraggio accademico per studenti e docenti

EduTrack

Team di tre, che ho guidato · 2026 · React, TypeScript, Supabase

In breve

EduTrack dà a uno studente un unico posto per tutto il percorso accademico: voti per modulo, assenze, attività e scadenze, sessioni di studio, un diario di riflessione e le analisi su tutto questo. I docenti seguono gli studenti dei loro gruppi e fanno l'appello.

Ho guidato un team di tre e costruito la maggior parte — lo schema del database e le sue migrazioni, il livello di accesso ai dati e l'interfaccia. È una single-page app in React e TypeScript su Supabase, il che significa che PostgreSQL fa più lavoro di quanto farebbe dietro un front end tradizionale.

Il problema

Gli studenti seguono i propri studi tra un foglio di calcolo, un'app di note e la memoria. I numeri che contano — una media che scende, assenze che si accumulano — restano sparsi finché è tardi per intervenire. EduTrack li riunisce, aggiornati appena un voto o un'assenza viene registrato.

C'è un secondo pubblico, e plasma il modello dei dati: i docenti devono seguire un gruppo senza vedere gli studenti che non ne fanno parte, mentre alcune cose — le riflessioni di uno studente, le sue sessioni di studio — riguardano solo lui. Chi vede cosa è quindi parte del prodotto, non un dettaglio aggiunto dopo.

Architettura

  • Supabase fornisce PostgreSQL, l'autenticazione e l'API. Lo schema vive in migrazioni SQL versionate, e un trigger crea il profilo di ogni utente nel momento in cui si registra.
  • La sicurezza a livello di riga è attiva su ogni tabella. Attività, voti e assenze di uno studente sono condivisi con i docenti dei suoi gruppi; riflessioni e sessioni di studio restano private.
  • I gruppi collegano docenti e studenti, e un'unica funzione nel database risponde a «questo docente ha questo studente?» per tutte le regole che devono saperlo.
  • Il client è in React con TypeScript e React Router. L'accesso ai dati passa da hook e servizi invece che dai componenti, e Recharts disegna le analisi.

Decisioni e compromessi

È il database a creare il profilo, non il client

Un utente senza una riga di profilo è un bug in attesa in ogni query che lo unisce ad altre tabelle. Creare il profilo con un trigger alla registrazione — nella stessa transazione dell'account — rende quello stato impossibile, invece di affidarsi al client perché se ne ricordi.

Gruppi, non un campo docente su ogni studente

Un docente ha più gruppi; uno studente può appartenere a più di uno. Modellarlo con i gruppi e due tabelle di appartenenza, e porre la domanda «questo docente ha questo studente?» attraverso un'unica funzione condivisa, fa sì che ogni regola di accesso ponga la stessa domanda nello stesso modo — un solo posto da capire, un solo posto da modificare.

Cosa è stato difficile

La sicurezza a livello di riga non perdona, in entrambe le direzioni. Una regola troppo larga lascia uscire dati in silenzio; una troppo stretta restituisce una lista vuota, che sembra esattamente l'assenza di dati. Aggiungere docenti e gruppi ha richiesto di sostituire in blocco le prime regole in una seconda migrazione, e di decidere, tabella per tabella, che cosa un docente dovesse raggiungere e che cosa dovesse restare privato.

Il resto era coordinamento: tre persone sullo stesso schema, dove una migrazione scritta da uno cambia ciò che restituiscono le query degli altri.

Risultato

Online e utilizzabile dall'inizio alla fine: registrarsi come studente o come docente, entrare in un gruppo e seguire un semestre — voti in ventesimi per modulo e per tipo, appello fatto dal docente per tutto il gruppo, attività con sotto-attività, e le analisi sopra a tutto.

I prossimi passi

Testare direttamente le regole di accesso. Ognuna è un piccolo programma, e per ora l'unica prova che si comporti bene è usare l'applicazione.

Poi costruire le due funzionalità che la landing page promette e che l'app non ha ancora: una media semestrale prevista, e un avviso prima che uno studente raggiunga il limite di assenze di un modulo.