Negli ultimi anni con i miei ragazzi ho lavorato molto con Ghost, CMS moderno che apprezzo per la sua eleganza e per la sua capacità di gestire contenuti con un’ottima esperienza editoriale. In linea teorica, sarebbe stato lo strumento perfetto anche per quei progetti in cui era necessario pubblicare molti post ogni giorno, spesso raccolti da fonti online di settore.
Ma la teoria, si sa, non sempre regge di fronte alla pratica.
Il problema dei volumi
Ghost funziona bene finché si resta entro una certa scala: qualche decina di articoli al giorno, magari distribuiti tra diverse rubriche. Quando però ci si trova a dover alimentare centinaia o migliaia di post quotidiani, presi da feed e fonti di categoria diverse, l’architettura di Ghost inizia a mostrare alcuni limiti importanti:
- Database sotto pressione: query sempre più pesanti e tempi di risposta in crescita.
- Gestione media che diventa rapidamente caotica e time consuming.
- Aggiornamenti continui che rischiano di rompere processi automatizzati già delicati.
Insomma, pur essendo un CMS eccellente, Ghost si è rivelato poco adatto a questa tipologia di scenario.
Il ritorno a Hugo
Di fronte a queste difficoltà, ho deciso di fare un passo indietro – o forse sarebbe meglio dire “di lato” – e di ricominciare a lavorare con Hugo, il generatore di siti statici che conosco e apprezzo da anni.
Hugo non è un CMS in senso stretto: non c’è un database, non c’è un pannello di amministrazione, non c’è nulla che rischi di collassare sotto il peso dei volumi. Tutto si riduce a file statici. Ed è proprio questa semplicità che diventa un punto di forza in scenari ad alta scala.
Le difficoltà ovviamente ci sono, e non sono di quelle facili da metabolizzare per tutti:
- Non c’è un backend di editing tradizionale, il che significa che tutte le fasi di lavorazione di un sito e quelle di pubblicazione — refactoring, compilazione, deployment, ecc. — vanno gestite da linea di comando.
- La gestione degli aggiornamenti in tempo reale, sia di struttura che di contenuto, è davvero complessa, specie se non si è davanti ad un computer e si deve operare su mobile.
- Serve progettare un workflow di automazione robusto per popolare e rigenerare completamente ogni volta l’intero sito.
Ma questi sono problemi tecnici risolvibili, e con un grande vantaggio: una volta generato il sito statico, le performance e la stabilità non sono paragonabili a quelle di nessun altro CMS dinamico in circolazione — siamo qualcosa tipo 100 a 1 in scenari critici.
Popolare Hugo via API
Sto lavorando su un progetto che richiede la messa online, con cadenza oraria, di migliaia di post aggiornati. Il flusso che sto mettendo a punto è quindi piuttosto lineare:
- Raccolta contenuti: ogni ora, script dedicati interrogano fonti di categoria (feed RSS, API, scraping controllato).
- Normalizzazione: i dati vengono filtrati, puliti e trasformati in file Markdown con i relativi metadati (titolo, autore, data, categoria).
- Inserimento in Hugo: i file vengono copiati nella cartella content/ del progetto Hugo, organizzati per sezione.
In pratica, il cuore del processo è un middleware di API ingestion: una pipeline che pesca i dati, li converte e li deposita dentro Hugo. Non c’è bisogno di DB, non c’è bisogno di pannelli: tutto è file.
Deploy in produzione
Una volta popolata la cartella content/, entra in gioco la parte di build e deploy:
- Hugo genera l’intero sito in HTML statico in pochi secondi, anche con migliaia di pagine.
- Un sistema di CI/CD (ad esempio GitHub Actions, GitLab CI o Jenkins) si occupa di triggerare la build ogni volta che arrivano nuovi contenuti.
- Il deploy avviene su server statici ottimizzati: NGINX, Netlify, Vercel, o lo stesso Hetzner via CDN e caching, stiamo ancora decidendo qual è la soluzione migliore.
Il risultato è un sito scalabile, stabile e rapidissimo, con tempi di risposta sempre costanti anche quando il volume dei contenuti cresce in maniera esponenziale.
Essere in grado di cambiare strumento, senza preconcetti, sempre!
In teoria Ghost poteva essere la scelta “perfetta”, ma la realtà dei grandi volumi di contenuti richiede strumenti più semplici, robusti e scalabili. Hugo, con la sua natura di generatore statico, mi permette di riprendere in mano questi progetti con la sicurezza che la piattaforma reggerà senza affanni.
Non è un percorso privo di sfide: costruire la pipeline API → Markdown → Build → Deploy ha richiesto attenzione e know-how tecnico. Ma una volta in piedi, il sistema diventa una macchina affidabile che trasforma l’overload di contenuti in un asset gestibile, sicuro e performante.
Quando il progetto sarà in produzione e di pubblico dominio, tornerò a parlarne nei dettagli qui.
