Rispondiamo subito alla domanda posta nel titolo: in estrema sintesi l’espressione headless Drupal (in italiano “Drupal senza testa”) viene normalmente riferita a un sito con un front-end completamente separato dal back-end di Drupal in cui sono memorizzati e gestiti i dati. Il framework front end, dunque, è responsabile di ciò che è visualizzato e visibile su schermo e basandosi sui dati che Drupal gestisce in back-end. Ciò elimina la “testa” di Drupal e di fatto lo libera dalle funzioni di controllo di un normale CMS.
Che cosa significa tutto ciò? Proviamo a scendere più in dettaglio.
Headless Drupal dalla versione 7
Negli ultimi anni con l’evoluzione delle tecnologie web è aumentata di pari passo la volontà/necessità di visualizzare i contenuti attraverso diversi dispositivi e piattaforme (convergenza multimediale). L’avvento di framework front-end JavaScript come Angular, Ember and React, ha offerto la possibilità di “disaccoppiare” la gestione dei dati puri dalla loro visualizzazione, ampliando di fatto le opportunità di fruizione da parte degli utenti. Dalla versione 7 di Drupal è possibile optare per una gestione “disaccoppiata”, appunto “headless”, dei contenuti web. Con Drupal 8 questa capacità è stata addirittura “impiantata” nel suo core.
Tradizionalmente la forza di Drupal consiste nella sua grande capacità di classificare, gestire e visualizzare i contenuti. Headless Drupal mantiene tutte le peculiarità della versione completa originale ma di fatto trasferisce la funzione di visualizzazione ad altri applicativi.
Quando utilizzare Headless Drupal?
Ma quando vale la pena utilizzarlo in questa modalità? Più che altro converrebbe chiedersi quando NON utilizzarlo. In questo caso la risposta è semplice: tutte le volte che non si desidera perdere una gestione integrata di tutte le funzionalità del CMS. La versione Headless Drupal, infatti, “rinuncia” ad alcune funzionalità che di fatto vengono meno con il “disaccoppiamento” tra front-end e back-end, come ad esempio la possibilità di visualizzare le anteprime di contenuti non ancora pubblicati e il controllo fluido del layout.
Quindi è fondamentale comprendere non tanto se questo modello sia giusto, o sbagliato, ma quanto piuttosto se si adatta al progetto di sviluppo web su cui si sta lavorando.
