Quando qualcuno mi chiede «ma tu cosa fai di preciso?», e rispondo «un po’ di frontend e un po’ di backend», vedo sempre la stessa faccia. Sono due parole che si sentono ovunque e quasi nessuno le spiega. Eppure l’idea dietro è semplice, e capirla aiuta anche chi un sito lo deve solo commissionare o gestire.
Io la spiego sempre con un ristorante. Funziona sorprendentemente bene.
Il sito come un ristorante
- La sala è il frontend: tutto quello che vedi e tocchi. Pagine, pulsanti, menu, il modulo per iscriverti. Deve essere comoda, ordinata e veloce.
- La cucina è il backend: la parte che il cliente non vede. Controlla chi sei, fa i conti, decide cosa si può fare e cosa no.
- La dispensa è il database: dove sono conservati utenti, articoli, ordini, prenotazioni.
- Il cameriere è l’API: porta le richieste dalla sala alla cucina e riporta i piatti. Ha un menu preciso di cose che si possono chiedere.
- La cassaforte è dove stanno password e chiavi segrete. In un progetto è un file a parte, di solito chiamato
.env.
Ti sembrerà ovvio, ma è proprio qui che molti progetti nascono storti: quando la sala si mette a cucinare.
La regola d’oro: la sala non cucina
Tutto quello che succede nel frontend, cioè nel browser, l’utente lo può vedere e modificare. Non serve essere hacker: basta premere F12. Quindi un prezzo calcolato nella pagina, o un controllo tipo «solo gli amministratori possono cancellare», se sta solo lì non protegge niente.
Per questo la cucina deve sempre ricontrollare. Il frontend può dire «hai inserito un’email non valida» per comodità, ma è il backend che decide se un ordine è valido, se un utente può vedere una pagina, quanto costa davvero il carrello. È la stessa cosa che racconto nella checklist per il vibe coding sicuro: le app fatte in fretta con l’AI cadono quasi sempre su questo punto.
Come metto in ordine le cartelle
Un progetto è una cartella piena di altre cartelle. Non esiste un ordine unico giusto, e molti framework ti danno già il loro. Però l’idea è sempre la stessa: ogni cosa ha un posto, e quel posto si capisce dal nome.
Nel frontend separo:
components: i pezzi che si riusano, come un pulsante, una scheda, la barra in alto;pages: le schermate vere, ognuna fatta con quei pezzi;services: le chiamate al cameriere, cioè le richieste al backend, tutte in un posto solo.
Nel backend il percorso di una richiesta è a tappe:
routes: l’elenco degli indirizzi a cui il backend risponde, il menu del cameriere;controllers: ricevono la richiesta e preparano la risposta, senza fare troppo da soli;services: dove sta la logica vera, tipo «calcola lo sconto» o «manda l’email di conferma»;models: la descrizione dei dati, cioè cosa c’è nella dispensa e come è collegato.
Sembra burocrazia, ma ha un vantaggio concreto. Tra sei mesi, quando lo sconto va cambiato, so esattamente in quale file cercare. Se tutto sta in tre file da duemila righe, invece, ogni modifica rischia di romperne un’altra.
Le chiavi in cassaforte
La password del database, la chiave per i pagamenti, quella per mandare le email: non vanno mai scritte dentro il codice. Si mettono nel file .env, che resta sul server e non finisce mai su GitHub o in una chat.
Il motivo è pratico. Il codice si copia, si condivide, si pubblica. Le chiavi no. E così lo stesso progetto può girare sul mio computer con un database di prova e online con quello vero, cambiando solo quel file.
La dispensa va pensata prima
Se c’è una cosa che rifarei sempre con più calma è il database. Una pagina brutta si sistema in un pomeriggio. Dati organizzati male restano lì, e ogni cosa costruita sopra se li porta dietro.
Non serve prevedere tutto. Basta fermarsi mezz’ora con carta e penna e rispondere a domande così: chi sono gli utenti, possono avere ruoli diversi, un ordine contiene più prodotti, un prodotto può stare in più categorie? Disegnare i collegamenti prima di scrivere codice evita la maggior parte dei rattoppi dopo.
Nomi chiari, sempre uguali
L’ultima cosa è la meno affascinante e forse la più utile: dare nomi che si capiscono. Una cartella varie, un file prova2-definitivo, una funzione fai() sono piccoli debiti che paghi ogni volta che riapri il progetto.
Scegli uno stile e tienilo ovunque: italiano o inglese, maiuscole o trattini, ma sempre lo stesso. Chi arriva dopo, e spesso sei tu stesso dopo qualche mese, ti ringrazierà.
Se ti stai chiedendo se per il tuo progetto serve davvero tutto questo o basta uno strumento già pronto, ne ho scritto in WordPress o sito custom. E se vuoi provare a costruire qualcosa con l’AI, parti dai sette passi per la prima app.