Come ho costruito il mio sito da Data Engineer

Ho costruito il mio sito da Data Engineer come tratterei un piccolo prodotto tecnico: frontend moderno, backend API, database PostgreSQL, autenticazione, storage, automazioni, dashboard dati, deploy su VPS e un giro serio di hardening prima della pubblicazione.

Non volevo una semplice vetrina con una bio e qualche progetto. Volevo uno spazio che mostrasse il mio modo di ragionare: partire da un'idea, darle un'architettura, collegare dati e contenuti, automatizzare dove ha senso, proteggere ciò che non deve essere pubblico e continuare a migliorare il sistema nel tempo.

Perché ho deciso di costruirlo da zero

Un portfolio può limitarsi a raccontare cosa sai fare. Io volevo che il sito lo dimostrasse anche nella sua struttura. Per questo l'ho progettato come una piattaforma viva: pagine pubbliche, area admin, blog, news, progetti, gestione immagini e contenuti multilingua.

Questa scelta mi ha costretto a prendere decisioni reali: come separare pubblico e privato, come gestire una bozza, come pubblicare in italiano e inglese, come validare input, come proteggere upload e come evitare che il frontend abbia privilegi che non dovrebbe avere.

L'architettura generale del progetto

Ho separato frontend, backend e database per mantenere chiari i confini: il frontend gestisce l'esperienza utente, FastAPI applica logica e controlli, Supabase conserva dati, autenticazione e media.

Lo stack tecnico

Per il frontend ho scelto React 19, TypeScript, Vite e Tailwind CSS. Volevo un'interfaccia rapida da sviluppare, modulare e abbastanza ordinata da crescere senza diventare fragile.

Per il backend ho usato FastAPI con Pydantic e API REST. Il backend non è un dettaglio accessorio: è il punto in cui valido richieste, controllo privilegi, gestisco upload e tengo separata la logica applicativa dall'interfaccia pubblica.

Per dati e servizi ho scelto Supabase: PostgreSQL come base dati, Supabase Auth per le sessioni, Supabase Storage per immagini e asset. Il frontend usa solo la chiave anonima, mentre le operazioni privilegiate passano dal backend dopo controlli espliciti.

Il CMS e il blog come banco di prova

Il blog è stata la prima parte in cui il progetto ha smesso di essere solo un sito e ha iniziato a comportarsi come un sistema editoriale. Ho lavorato su editor TipTap, cover image, contenuti HTML, slug, categorie, stati di pubblicazione e versioni separate per italiano e inglese.

Qui sono emersi i dettagli che rendono interessante un progetto vero: uno slug vuoto può rompere un vincolo unico, una bozza non deve essere visibile fuori dall'admin, un contenuto HTML va sanitizzato, una media library deve leggere dal bucket corretto e un post pubblicato deve restare coerente tra API, database e frontend.

Automazioni AI con n8n

Sto usando n8n per ricevere e organizzare aggiornamenti sulle news legate all'intelligenza artificiale. Mi interessa costruire un flusso che raccolga segnali, fonti e novità in modo ordinato, perché restare aggiornato non significa solo leggere tanto: significa creare un processo.

Questa parte è molto vicina al Data Engineering: orchestrazione, fonti, trasformazione, filtri, controllo umano e pubblicazione. È un piccolo workflow, ma ragiona con la stessa logica di una pipeline.

Dashboard dati e percorso da Data Engineer

Ho previsto anche una dashboard per analizzare dati e visualizzare insight usando tecnologie e concetti che sto studiando nel Master Data Engineer. Per me è un modo concreto per trasformare lo studio in pratica: dataset, metriche, pipeline, visualizzazione e ragionamento data-driven.

Il sito diventa così anche un ambiente di apprendimento: non solo un posto dove mostrare risultati finiti, ma uno spazio dove collegare studio, esperimenti e contenuti misurabili.

Deploy con Docker su VPS

Ho containerizzato il progetto con Docker e l'ho portato su una VPS. Questo passaggio è stato importante perché mi ha fatto uscire dal classico "funziona in locale" e mi ha portato su temi più concreti: variabili d'ambiente, servizi, configurazione, stabilità e gestione di una macchina reale.

Non è la parte più visibile per chi legge il sito, ma è una delle più formative per chi lo costruisce.

Sicurezza, RLS e controlli prima della pubblicazione

La parte di hardening è stata una delle più utili. Abbiamo controllato dipendenze, file sensibili, CORS, security headers, token, XSS, upload, endpoint pubblici e protetti. Soprattutto, abbiamo separato meglio utente autenticato e utente admin.

Su Supabase ho lavorato sulle policy RLS per evitare che contenuti draft, pending o non pubblicati fossero leggibili tramite accesso diretto con anon key. Il principio che mi porto dietro è semplice: il frontend può filtrare, il backend può controllare, ma anche il database deve avere le sue regole.

Cosa mi porto a casa

Questo progetto mi rappresenta perché unisce le cose che mi interessano di più: dati, backend, automazioni, sicurezza, deploy e apprendimento continuo. Ogni scelta ha aperto una domanda nuova e ogni problema corretto ha reso il sistema un po' più solido.

Il sito continuerà a evolvere insieme al mio percorso da Data Engineer. Voglio usarlo per raccontare progetti, esperimenti, tecnologie che studio e soluzioni che costruisco, con lo stesso approccio: curiosità, metodo e voglia di capire davvero come funzionano le cose.