«Mi serve un sito» copre tre progetti che, dal punto di vista tecnico, hanno poco in comune fra loro. La distinzione non è di dimensione — esistono vetrine da duecento pagine e web app da tre schermate — ma di dove vive lo stato: quante informazioni cambiano, chi le cambia, e cosa succede se due cambiamenti si scontrano.
Le tre domande#
Tre domande che classificano un progetto meglio di qualunquedescrizione a parole. Rispondere richiede cinque minuti e cambiail preventivo di un ordine di grandezza. 1. CHI PRODUCE I DATI? Li produco io, e cambiano di rado → vetrina Li producono i clienti che comprano → e-commerce Li producono utenti che lavorano dentro → web app 2. QUANTE ENTITÀ CI SONO, E COME SONO LEGATE? Pagine indipendenti → contenuto Entità collegate (utente↔ordine↔prodotto) → modello dati 3. CI SONO STATI CHE DEVONO RESTARE COERENTI FRA LORO? No → vetrina Sì (denaro, magazzino, prenotazioni) → servono transazioni, e il progetto è nella fascia alta a prescindere da quanto sembri semplice l'interfacciaVetrina: quasi nessuno stato#
// Vetrina: l'unico stato è il modulo di contatto. Il resto è// contenuto, uguale per tutti, quindi mettibile in cache senza// alcuna complicazione.app.get('/servizi', (req, res) => { res.set('Cache-Control', 'no-cache'); // rivalidazione, vedi cache busting res.type('html').send(layout(pagine.servizi));});// Conseguenze pratiche:// - la scalabilità è quasi gratuita: mille visitatori simultanei// ricevono lo stesso identico byte;// - non c'è un database da amministrare né da salvare;// - il lavoro si concentra su contenuti, prestazioni, SEO tecnica// e accessibilità — che è lavoro vero, ma di natura diversa.Quando il contenuto è uguale per tutti, la scalabilità è quasi gratuita: mille visitatori simultanei ricevono lo stesso identico byte, che può essere prodotto una volta e riusato. Non c'è un database da amministrare, da salvare e da ripristinare, e la superficie d'attacco si riduce al modulo di contatto.
Il lavoro non sparisce: si sposta su contenuti, struttura, prestazioni, SEO tecnica e accessibilità. È lavoro vero e ha un valore misurabile — ma è di natura diversa, e non cresce nel tempo come quello di un sistema con stato.
E-commerce: il lavoro sta nei percorsi che vanno male#
// E-commerce: il problema che definisce la categoria non è il// carrello. È che denaro e disponibilità devono restare allineati// anche quando qualcosa si interrompe a metà.//// I quattro percorsi che vanno previsti, e che costituiscono la// maggior parte del lavoro reale:// 1. Il browser si chiude durante il pagamento.// → lo stato dell'ordine NON può dipendere dal ritorno del// visitatore sulla pagina di conferma.// 2. Il gateway conferma con un webhook in ritardo (o due volte).// → il webhook è la fonte di verità, e va reso idempotente.app.post('/webhook/pagamenti', async (req, res) => { if (!firmaValida(req.rawBody, req.get('signature'))) return res.status(400).end(); const ev = JSON.parse(req.rawBody); // Se questo evento è già stato elaborato, si esce senza rifare nulla. const nuovo = await db.run( 'INSERT OR IGNORE INTO eventi_gateway (id) VALUES (?)', [ev.id]); if (nuovo.changes === 0) return res.status(200).end(); await applica(ev); res.status(200).end();});// 3. Due clic sul pulsante di acquisto.// → chiave di idempotenza generata dal client (vedi race condition).// 4. L'ultimo pezzo in magazzino conteso da due carrelli.// → la disponibilità si decide con un UPDATE condizionale, non// con un controllo seguito da una scrittura.Questa è la parte che sorprende chi commissiona il progetto. Il percorso felice — l'utente sceglie, paga, riceve la conferma — si costruisce in una frazione del tempo. La maggior parte del lavoro sta nei quattro casi elencati, che non si vedono in nessun mockup e che costituiscono la differenza fra un negozio che funziona e uno che ogni settimana produce un ordine da sistemare a mano.
Il secondo caso merita una nota: il webhook è la fonte di verità, non il ritorno del browser. Il visitatore può chiudere la scheda un istante dopo aver pagato, e l'ordine deve risultare pagato lo stesso. E poiché i gateway ritentano i webhook quando non ricevono conferma, la loro elaborazione deve essere idempotente — la stessa notifica ricevuta due volte non deve produrre due ordini.
Le regole non tecniche che diventano codice, e che nessuno mettenel preventivo iniziale perché non si vedono nell'interfaccia: IVA aliquote diverse per categoria, regimi speciali, vendite intracomunitarie, e la STORIA delle aliquote (una fattura del 2012 va ristampata con l'aliquota del 2012) Spedizioni scaglioni di peso, zone, corrieri, soglie di gratuità, isole e zone disagiate Resi finestra temporale, stato della merce, rimborso parziale, ripristino della giacenza Fatturazione numerazione progressiva senza buchi, formato elettronico, note di credito Stati dell'ordine ricevuto, pagato, in preparazione, spedito, consegnato, annullato, rimborsato — con le transizioni AMMESSE fra loroL'ultima riga è quella che vale la pena disegnare per prima:una macchina a stati esplicita, con le transizioni consentite,previene la maggior parte degli stati impossibili.L'ultima riga vale un disegno prima di scrivere codice: una macchina a stati esplicita, con l'elenco delle transizioni ammesse. Previene la maggior parte degli stati impossibili — un ordine rimborsato che risulta anche in preparazione, un annullamento su qualcosa già consegnato — che altrimenti si scoprono in produzione, uno alla volta.
Web app: tre costi che non si vedono#
// Web app: non racconta un'attività, la fa funzionare. Il costo si// sposta su tre punti, e nessuno dei tre si vede nell'interfaccia.// 1. MODELLO DATI — entità, relazioni, vincoli// Sbagliarlo è la decisione più costosa da correggere, perché// quando ce ne si accorge ci sono già dati dentro.// 2. AUTORIZZAZIONE — su ogni endpoint, a ogni richiesta// Il perimetro sta nella query, non in un controllo dopo:const fattura = await db.get( 'SELECT * FROM fatture WHERE id = ? AND org_id = ?', [id, sessione.organizzazione] // ← senza, la riga non esce);// 3. MIGRAZIONI — lo schema cambierà mentre il sistema è in uso// Una web app senza un meccanismo di migrazione versionato è// una web app che non si potrà aggiornare senza fermate e// interventi manuali sul database.Il primo è il più costoso da sbagliare. Un modello dati inadeguato si corregge finché il sistema è vuoto; dopo sei mesi di uso ci sono dati dentro, e la correzione diventa una migrazione con rischio di perdita. Vale la pena spendere qualche giorno in più all'inizio su entità, relazioni e vincoli.
Il secondo è quello che produce gli incidenti: l'autorizzazione va verificata su ogni richiesta, e il modo robusto è metterla nella query invece che in un controllo separato — come discusso in forced browsing e IDOR.
Il terzo è quello che si scopre al primo aggiornamento: lo schema cambierà mentre il sistema è in uso, e senza un meccanismo di migrazione versionato ogni aggiornamento diventa una fermata con interventi manuali sul database.
Il caso ibrido#
Il caso ibrido più frequente, e perché va deciso PRIMA: vetrina + area riservata clientiSembra "una pagina in più". Non lo è. Significa introdurre: - autenticazione (registrazione, accesso, reset, sessioni) - archiviazione persistente dove prima non c'era - un modello di permessi - backup e ripristino verificati - obblighi privacy diversi (si trattano dati di account) - una superficie d'attacco che prima era quasi nullaÈ fattibile e spesso è la scelta giusta. Ma è una delle pochedecisioni davvero costose da rimandare: aggiungerla a un sitonato per essere statico significa cambiare architettura, nonaggiungere una schermata.Dove finisce il tempo#
# Dove finisce il tempo, in proporzione. Non sono preventivi:# sono le proporzioni tipiche, utili per capire dove guardare.# VETRINA# contenuti e struttura ████████████████ 40%# design e front-end ████████████ 30%# prestazioni, SEO, a11y ████████ 20%# pubblicazione ████ 10%# E-COMMERCE# percorsi che vanno male ████████████████ 40% ← la sorpresa# regole di dominio ████████████ 30%# catalogo e interfaccia ████████ 20%# pubblicazione e sicurezza ████ 10%# WEB APP# modello dati e permessi ████████████████ 40%# interfaccia e stato ████████████ 30%# migrazioni e operativita' ████████ 20%# test ████ 10%| Vetrina | E-commerce | Web app | |
|---|---|---|---|
| Dove vive lo stato | quasi nessuno | ordini, pagamenti, magazzino | dominio + permessi |
| Servono transazioni | no | sì | sì |
| Database | facoltativo | necessario | necessario |
| Autenticazione | no | per i clienti | centrale |
| Scalabilità | quasi gratuita | da progettare | da progettare |
| Backup | il repository | critico | critico |
| Costo di manutenzione | basso, stabile | alto e continuo | medio, cresce con le funzioni |
| Rischio principale | contenuti che invecchiano | incoerenze fra denaro e merce | modello dati sbagliato |
| Cambia idea dopo? | facile aggiungere | difficile togliere | difficile cambiare il modello |
La riga da leggere per ultima è quella sulla manutenzione. Una vetrina fatta bene ha un costo di esercizio che tende a zero: aggiornamenti di sicurezza, qualche contenuto, poco altro. Un e-commerce ha un costo continuo e non comprimibile — regole che cambiano, integrazioni che si rompono, casi da riconciliare — e va messo in conto nel budget annuale, non solo in quello iniziale.