Build e deploy

Hai un sito che funziona in sviluppo. Alla fine di questo capitolo sarà online, e saprai cosa è stato deciso a build e cosa resta deciso a runtime.

Gli store non vengono letti dal filesystem a runtime: sono importati come moduli, quindi finiscono nel bundle. È il motivo per cui il percorso di render non tocca il disco e funziona su un ambiente serverless.

Le classi che compaiono negli store vengono generate da Tailwind, che legge quei file come sorgenti. Una classe che esiste solo in un valore di database e in nessuno store non viene generata — e quindi non esiste nel CSS.

Serve un database raggiungibile e le variabili d’ambiente: la chiave di Payload e l’indirizzo del database.

Il build interroga il database, quindi va fatto con quelle variabili presenti.

Metti una classe direttamente nel className di un blocco in database, senza che compaia in nessuno store. In sviluppo la vedi, in produzione no.

È la trappola più costosa del sistema, perché sviluppo e produzione si comportano diversamente e la differenza compare solo dopo il deploy. Se una classe deve esistere, deve stare in uno store.

Hai coperto il sistema: fondamenta, forma, contenuto, comportamento, stato, estensione, strumenti, produzione. Quello che resta sono i casi interi — un sito vero costruito da zero — e sono un contenuto a parte.