piccolopellegrino.dev
Sito web · Rilasciato: ott 2026
Il mio portfolio personale: un sito Next.js esportato staticamente e gestito con Sanity, dove ogni progetto è presentato come un piccolo case study con architettura e decisioni tecniche.
01 — Galleria
L'app, schermata per schermata
Uno sguardo alle schermate principali dell'app.
02 — Architettura
Com'è fatta
L'app, livello per livello. Ogni badge rimanda alla decisione che ha definito quel livello.
PIPELINE DI BUILD
Sanity Studio
Gestione dei contenuti
Content Lake
Sanity · API GROQ
Build Next.js
Export statico
Sito statico
Pagine pre-renderizzate
Modulo di contatto
Servizio esterno per i moduli
Server applicativo
Nessun server, nessuna API route
03 — Decisioni
Registro delle decisioni
Contesto, scelta e il prezzo pagato per ognuna.
Export statico invece del rendering lato server
Contesto
I contenuti cambiano raramente e il sito non ha dati specifici per utente.
Decisione
Compilare l'intero sito con Next.js output: "export" e servirlo come file statici.
Compromesso
Per aggiornare i contenuti serve una nuova build, e le funzioni lato server (API route, ottimizzazione delle immagini) non sono disponibili.
Alternative
SSR su un server Node, ISR su Vercel
Sanity come CMS headless
Contesto
Ogni progetto è un case study strutturato (livelli, decisioni, galleria), scomodo da mantenere in file Markdown.
Decisione
Modellare i progetti in Sanity con campi tipizzati e validazione, modificati in uno Studio personalizzato.
Compromesso
Aggiunge una dipendenza esterna, e i contenuti vivono fuori dal repository.
Alternative
File MDX nel repository, File JSON
Build in un clic dallo Studio
Contesto
Un sito statico va ricompilato per mostrare i nuovi contenuti.
Decisione
Uno strumento "Update Site" nello Studio, protetto da password, avvia una build solo quando lo decido io.
Compromesso
Pubblicazione e deploy sono due passaggi separati.
Alternative
Webhook a ogni pubblicazione, Build programmate
Modulo di contatto senza backend
Contesto
Il modulo di contatto è l'unica funzione dinamica del sito.
Decisione
Inviare i dati a un servizio esterno per i moduli direttamente dal browser.
Compromesso
Dipende da un servizio esterno e dai suoi limiti.
Alternative
Funzione serverless, Semplice link mailto
Query GROQ tipizzate
Contesto
Una modifica allo schema potrebbe rompere il frontend senza che nessuno se ne accorga.
Decisione
Generare i tipi TypeScript dallo schema e dalle query con Sanity TypeGen.
Compromesso
C'è un passaggio di generazione in più dopo ogni modifica dello schema.
Alternative
Tipi scritti a mano, GraphQL con codegen