fbpx

Scegliere tra un CMS tradizionale come WordPress o un CMS Headless

Quando la gestione dei contenuti è uno dei requisiti fondamentali di un progetto per il web, la scelta ricade tipicamente tra le piattaforme di Web Content Management tradizionali e quelle headless.

Vi è poi la possibilità, utilizzando CMS “decoupled”, dove cioè contenuto e presentazione sono disaccoppiati, di utilizzare sia un approccio headless che tradizionale. In questo caso specifico, un CMS tradizionale può funzionare anche come CMS headless.

Per semplificare, rimaniamo alle differenze fondamentali tra questi due approcci:

  • Le piattaforme CMS tradizionali come WordPress, Drupal, Joomla e simili, tipicamente “monolitiche”, sono basate su editor di tipo WYSIWYG e temi grafici applicati lato frontend pubblico che possono essere adattati per molte tipologie di siti.
  • Le piattaforme headless come eZ Platform, Contentful e simili, invece, sono tali se erogano soltanto contenuti in forma di dati, senza interfaccia utente. In un CMS di questo tipo, il contenuto viene fornito dalla piattaforma tramite delle API dedicate che vengono integrate in un’applicazione personalizzata scritta appositamente.

Quindi, da una parte un CMS tradizionale offre un modo per salvare e immagazzinare contenuti, un’interfaccia web per crearli e modificarli e un’applicazione web con un tema grafico applicato per mostrarli al pubblico.

Un CMS headless invece si concentra sulle prime due parti, spezzando quell’accoppiamento stretto che c’è tra il backoffice e il frontend di un CMS tradizionale, offrendo quindi sempre un modo per immagazzinare contenuti e crearli/modificarli, ma aggiungendo delle API a disposizione degli sviluppatori per distribuire i contenuti in frontend dedicati.

Questo comporta anche il fatto che quando si creano contenuti in un CMS headless, questi contenuti vengono inseriti e salvati in un formato “grezzo” in termini di testi, immagini, media, titoli, valori in generale, ecc., senza il layout o elementi di visual design.

Questi contenuti possono poi essere mostrati nel modo più appropriato in ciascun canale o applicazione che consuma le API del CMS headless (es. un sito web, un’applicazione mobile, ecc.).

Diventa quindi responsabilità dell’applicazione che consuma le API fornire il layout e il design visuale del contenuto da mostrare agli utenti.

Questo può avvenire anche in un CMS tradizionale se strutturato in quel modo (anche WordPress ha la sua API REST), ma se per un CMS headless è alla base dell’architettura stessa, per un CMS tradizionale è un qualcosa in più che spesso deve piegare lo strumento a fare qualcosa per cui non era progettato (v. formattazione da ripulire dal contenuto erogato tramite API).

Le piattaforme headless tendono ad essere più moderne, anche per via del fatto che si tratta di un paradigma più recente di quello tradizionale, tuttavia vi sono casi in cui è del tutto appropriato continuare ad usare CMS di quest’ultimo genere.

Vantaggi dei CMS tradizionali

Ci sono molte situazioni in cui un CMS tradizionali è una buona scelta, come ad esempio:

  • Non c’è già un sito preesistente o non si hanno requisiti od opinioni particolari lato tecnico e quindi non ci sono problemi ad adottare uno specifico stack tecnologico (es. PHP con MySQL).
  • Si hanno già a disposizione degli sviluppatori Drupal, WordPress e/o PHP.
  • È possibile dare in outsourcing tutto lo sviluppo di un sito WordPress ad un’agenzia.
  • La necessità è quella di avere un semplice sito “vetrina” stand-alone o ad uso del marketing senza necessità di integrarlo con altri stack tecnologici o applicazioni che hanno bisogno di un CMS.
  • Un CMS tradizionale come WordPress è sicuramente utile se si desidera utilizzare temi e modelli già pronti e integrati nella piattaforma come base di partenza da personalizzare.

Più nello specifico, ecco una serie di vantaggi di cui godono i CMS tradizionali.

Familiarità

I CMS tradizionali hanno il vantaggio di essere più familiari visto che esistono da molti più anni, e una parte di questa familiarità deriva dal comfort nell’utilizzarli.

Ad esempio, per i blogger una piattaforma come WordPress è tendenzialmente quella più diffusa e ci è capitato di dover creare piattaforme ad alto traffico per network di centinaia di blogger dove avere un backend basato su WordPress era un requisito fondamentale per non far fuggire i blogger.

Barriera d’ingresso più bassa

Con un CMS di tipo tradizionale, la barriera d’ingresso a livello tecnico è normalmente più bassa.

Se nel tuo team non ci sono sviluppatori (interni o esterni), non è una buona idea scegliere un CMS headless.

I CMS tradizionali come WordPress mettono a disposizione un sistema “auto contenuto” che tende ad offrire tutto ciò che serve per mettere un utente non tecnico nelle condizioni di gestire contenuti in maniera flessibile, tramite editor WYSIWYG (anche a blocchi gestibili), temi standard e tutorial per imparare a contribuire contenuti, implementare funzionalità di base come un blog, aggiungere una sezione eCommerce, ecc.

Time to Market ridotto

Usare un CMS completo con un tema già pronto di quelli che si possono acquistare online può ridurre il time to market per andare online con un sito pronto.

Si possono trovare grandi quantità di temi già pronti per molti casi d’uso comuni (blog, ecommerce, siti per settori verticali specifici, ecc.), che possono essere personalizzati senza troppo sforzo per aderire alle linee guida del proprio brand.

Convenienza di avere tutto in un solo posto

Un CMS tradizionale ha la convenienza di fornire tutte le funzionalità e le caratteristiche fondamentali sotto un unico tetto, strettamente accoppiate e già pronte per essere utilizzate.

L’intero sito è quindi gestito ed erogato tramite un unico sistema:

  • Un pannello per gestire il sito e i contenuti.
  • Un database.
  • Un tema grafico.
  • Il codice per trasformare i contenuti presenti nel database in un sito web basato sul tema.

Possibilità di vedere i contenuti in anteprima

In un CMS tradizionale la parte di frontend è integrata con il CMS stesso ed è perciò possibile vedere i contenuti in anteprima anche se non sono ancora stati pubblicati.

Con un CMS headless questo potrebbe non essere possibile. Alcune piattaforme consentono di costruire un’integrazione per l’anteprima dei contenuti, ma richiedendo di solito di dedicare del tempo.

Vantaggi dei CMS headless

Alcuni dei casi in cui conviene invece utilizzare un CMS headless sono questi:

  • L’esigenza è di pubblicare i contenuti su più canali contemporaneamente ed è necessario avere il pieno controllo di come e quando i contenuti vengono distribuiti tra i vari canali e dispositivi come smartphone, tablet, desktop, dispositivi IoT, wearables, digital signage, o addirittura canali o dispositivi non ancora definiti, ecc.
  • Non si vuole avere a che fare con le problematiche tipiche di un sito basato su un CMS come l’hosting, la scalabilità e la manutenzione, rivolgendosi ad una piattaforma headless di tipo SaaS (o, più precisamente, CaaS: Content as a Service).
  • Si ha già una piattaforma o un sito web costruito con un moderno stack tecnologico specifico come ad esempio React, Django, Symfony, Node.js, ecc. e l’esigenza è quella di integrarlo rapidamente con un sistema di gestione contenuti, senza dover piegare queste tecnologie a quelle dei CMS tradizionali.
  • Quando il sito da realizzare utilizza dei framework in Javascript come Angular, React o VueJs.
  • Si ha bisogno di performance e velocità elevate senza dover gestire grandi quantità di codice, tipiche dei CMS tradizionali.
  • Si ha intenzione di usare un generatore di siti statici.

Alcuni dei vantaggi dei CMS Headless più in dettaglio sono i seguenti:

Maggiore sicurezza

Nel caso di un CMS tradizionale, avere tutte le funzionalità già pronte in un unico scatolone si traduce tipicamente in grandi quantità di codice e file.

Questo comporta che potenzialmente ci possano essere molte vulnerabilità che possono essere sfruttate in caso di attacchi, come spesso avviene ad esempio sui siti WordPress.

E’ molto probabile che ci possano essere errori in quella grande quantità di file che compongono un CMS tradizionale (anche se questo è un problema che affligge il codice a prescindere), con problemi quali parametri nelle query string gestiti male che possono tradursi nell’eliminazione dei dati o nel renderli pubblici bypassando le regole.

Questo a sua volta comporta la necessità di aggiornare frequentemente il CMS e i plugin installati con le nuove versioni che correggono i problemi di sicurezza, prima che vengano sfruttati da soggetti malintenzionati.

Da questo punto di vista, una piattaforma headless è tipicamente più sicura.

Migliore supporto cross-platform

I CMS headless sono in grado di fornire i contenuti in forma di dati che possono essere usati sostanzialmente da qualsiasi client, dispositivo e linguaggio.

Questo tipo di flessibilità consente di prendere le decisioni tecnologiche più adatte per il dominio e il tipo di applicazione di ciascuna situazione, ad esempio quando si deve sviluppare un prodotto digitale con un client web e uno mobile.

In questo senso, un CMS headless è agnostico rispetto al tipo di frontend e si limita a erogare il contenuto in forma di API, consentendo agli sviluppatori di decidere liberamente quali strumenti e framework utilizzare per mostrare il contenuto.

Maggiore indipendenza dalla piattaforma

Il fatto di utilizzare un CMS headless può rendere più facile decidere di cambiare piattaforma di gestione contenuti in un secondo momento.

Questo perché è più facile astrarre le interazioni con il CMS dalla parte del client introducendo uno strato applicativo intermedio.

In questo modo, cambiare CMS richiederebbe di aggiornare il codice intermedio, non l’intero codice del client che consuma le API.

Premesso che il problema della migrazione dei contenuti può essere un grande ostacolo a prescindere dal tipo di approccio (tradizionale o headless), anche tra CMS tradizionali è possibile cambiare piattaforma ma di solito il processo è alquanto problematico.

Maggiore scalabilità

Un CMS tradizionale è tipicamente monolitico (è il rovescio della medaglia di avere tutto in un unico posto).

Questo significa che rendere scalabile un CMS di quel tipo è spesso molto più difficoltoso.

Un CMS headless è invece per sua architettura molto più scalabile, soprattutto quando il client che lo consuma è un’applicazione Javascript come una Single Page Application.

Inoltre, come già accennato i CMS headless sono più recenti e tendono ad essere sviluppati con paradigmi di sviluppo e architettura del codice più moderni e sono spesso scalabili nativamente.

Molto più developer-friendly

Poiché la scelta di una soluzione headless richiede un elevato know how tecnico e a sua volta è tipicamente progettata con moderni paradigmi di sviluppo, un CMS di questo tipo è normalmente molto più developer-friendly.

Viceversa, chiedere ad un bravo sviluppatore di lavorare su piattaforme come WordPress può essere… repellente. È sufficiente chiedere agli sviluppatori e la maggior parte risponderanno che lavorare su sistemi di Web Content Management di quel tipo non è propriamente in cima alla loro lista dei lavori più interessanti.

I CMS headless rimuovono buona parte di questi problemi (in particolare quando sono utilizzati in modalità CaaS) in modo che il team di sviluppo possa svolgere bene il proprio lavoro e passare ad altri progetti.

Conclusioni

Sebbene non ci sia una soluzione in grado di risolvere tutti i problemi, in base ai criteri elencati sopra è possibile valutare meglio le proprie opzioni quando si tratta di scegliere il tipo di CMS.

Oltre a questi due tipi principali, le varianti disponibili all’interno di ciascuna categoria sono tante e, tendenzialmente, sceglierne una piuttosto che un’altra di vendor differenti va spesso in funzione delle preferenze e di esigenze più specifiche.

Entrambe le soluzioni sono quindi fattibili a seconda della situazione, dell’architettura e degli obiettivi di gestione dei contenuto a lungo termine.

Per alcuni siti, un CMS tradizionale è una strada adeguata. Per altri, un CMS headless è la soluzione ottimale.

Ad esempio, quando lavoriamo con i nostri clienti per definire il percorso migliore dobbiamo sempre guardare al quadro generale e alle tendenze di mercato per assicurarci di porre le basi per la crescita futura del progetto e sfruttare correttamente le varie innovazioni tecnologiche.

Risorse

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Compila questo campo
Compila questo campo
Inserire un indirizzo email valido.
Devi accettare i termini per procedere

Menu