"Headless CMS pronto in 5 minuti" è la promessa di ogni pagina di marketing di Strapi. Ed è vera, per i primi 5 minuti. Il primo content type lo crei senza scrivere una riga di codice, l'admin panel è pulito, e in mezza giornata hai già un'API REST o GraphQL che risponde. Poi arriva il primo progetto vero, con relazioni tra contenuti, permessi diversi per ruoli diversi, e traffico reale — ed è lì che Strapi va giudicato davvero.
Dove regge
Il punto di forza più concreto è il content modeling. Puoi costruire strutture complesse — relazioni many-to-many, componenti riutilizzabili, dynamic zone — senza dover scrivere migrazioni a mano. Per un progetto con un backend content-heavy ma requisiti custom (non il classico blog, ma qualcosa con logiche di business proprie), è un risparmio di tempo reale rispetto a costruire un CMS da zero.
L'altro vantaggio è il self-hosting. Strapi gira su Node, quindi lo metti dove vuoi — nel mio caso su un VPS gestito con Proxmox — senza dipendere da un servizio SaaS terzo o da limiti di piano. Se hai già infrastruttura tua, questo pesa parecchio sui costi a lungo termine.
Anche l'ecosistema dei plugin aiuta più di quanto mi aspettassi: autenticazione, upload su storage esterno, internazionalizzazione dei contenuti sono tutte cose che arrivano già pronte o quasi.
Dove mi ha creato grattacapi
Il primo dolore serio è arrivato con le relazioni complesse: query con più livelli di populate diventano pesanti in fretta, e senza un lavoro attivo di ottimizzazione (indici, populate mirati invece che *, caching a monte) le performance calano visibilmente non appena il dataset cresce.
Il secondo è la gestione di permessi e ruoli. Il sistema è flessibile, ma configurarlo bene per scenari reali — un editor che può modificare solo certi contenuti, un'API pubblica che deve esporre solo certi campi — richiede più attenzione di quanto l'admin panel lasci intuire all'inizio. È facile esporre per errore un campo o un endpoint che non dovrebbe essere pubblico.
Il terzo, e forse il più fastidioso nel tempo, sono gli upgrade tra versioni maggiori. Strapi si evolve rapidamente, e passare da una major all'altra ha significato più di una volta rivedere plugin custom o configurazioni che non erano più compatibili as-is.
Per chi ha senso
Strapi ha senso se hai (o puoi costruire) un minimo di competenza infra per gestire il self-hosting, e se il progetto ha davvero bisogno di un content model custom che un CMS "a blocchi" non ti darebbe facilmente. Ha molto meno senso se il progetto è principalmente editoriale — un blog, un sito vetrina — dove la flessibilità che offre resta in gran parte inutilizzata a fronte di un costo di manutenzione che qualcun altro (WordPress, un CMS nativo per il tuo framework) si prenderebbe gratis.
Il consiglio pratico
Se parti da zero con Strapi, blocca la versione all'inizio del progetto e testa il percorso di aggiornamento in un ambiente separato prima di portarlo in produzione. È il passaggio che salta quasi tutti, ed è quello che poi costa più ore quando arriva davvero il momento di aggiornare.
