Per gran parte di undici anni, il mio riflesso quando qualcosa richiedeva un backend era scriverne uno. Non perché fosse sempre la scelta giusta, ma perché costruire è la parte che mi piace ed ero abbastanza bravo da potermi permettere l'abitudine. Per un lungo periodo quell'abitudine è stata una tassa che pagavo al mio stesso ego, e mi dicevo che era artigianato. All'inizio del 2025 ho finalmente smesso di pagarla, almeno per un progetto.
Il mio portfolio è sempre stato un progetto di cui sono orgoglioso, ma le sue fondamenta erano diventate una capsula del tempo. Per anni un piccolo backend in PHP leggeva i dati da file INI; poi il frontend leggeva semplicemente JSON grezzo direttamente dal disco. La presentazione era curata e il flusso di lavoro era penoso. Ogni refuso, ogni aggiornamento di un progetto significava aprire un editor, modificare un file, fare un commit. Ricordo di aver voluto correggere una singola frase dal telefono, lontano dalla scrivania, e di essermi reso conto che non potevo farlo senza un deploy completo. È stato il momento in cui l'abitudine ha smesso di sembrare artigianato e ha iniziato a sembrare una gabbia che mi ero costruito da solo.
Non volevo costruire a mano un'interfaccia di amministrazione dal nulla — anche io sentivo l'ego in quell'idea — così sono andato a vedere cosa esisteva già. La ricerca mi ha riportato al CMS headless: il frontend completamente separato dall'archivio dei contenuti, i dati serviti ovunque tramite un'API. Avevo già lavorato con questa forma su scala aziendale, ma non avevo seguito quanto fossero cresciuti gli strumenti indipendenti.
I giganti SaaS — Contentful e i suoi vicini — sono davvero capaci, e fanno anche pagare a record, con tetti di API che si leggono come un conto alla rovescia per qualsiasi cosa cresca. Non volevo una fattura di abbonamento che mi punisse per aver usato il mio stesso sito. Volevo possedere il codice e il database, senza mezzi termini.
Così ho guardato solo cose che potessi ospitare da solo, e ho esaminato quelle che la gente usa davvero:
Strapi si collocava nello spazio tra un'applicazione finita e un framework. L'interfaccia è abbastanza buona da permettermi di fare una modifica dal telefono, e non chiude mai la porta al codice: gira su Node, quindi un hook del ciclo di vita o un controller su misura sono lì quando un CMS standard mi lascerebbe bloccato. Trattava sei lingue come oggetti di prima classe invece che come un ripensamento, mi lasciava dare forma agli schemi senza scriverli a mano, e trasformava un articolo in qualcosa di modulare: blocchi che potevo impilare invece di un unico blocco di markup.
Quando ho avviato questo blog qualche mese dopo, non ho ricominciato da capo. Ho esteso i modelli che avevo già e ho puntato un secondo frontend verso di essi. Il lettore di file statici era diventato un motore al servizio di due progetti.
Niente di tutto questo è stato una storia di conversione. Ricorro ancora a una costruzione da zero più spesso di quanto dovrei, e penso ancora che quell'istinto valga la pena averlo. Ma appartiene ai progetti in cui sbagliare costa solo a me — non all'unico pezzo di infrastruttura che deve essere noioso e affidabile. Scegliere lo strumento qui era la decisione più difficile, e per una volta l'ho presa.
Le fondamenta sono gettate; ora si costruisce.