CMS headless
Con un sistema di gestione dei contenuti headless, il back-end e il front-end sono ora separati, o “disaccoppiati”.
La parte headless è il back-end del contenuto, in quanto un sistema di gestione dei contenuti headless è un sistema di gestione dei contenuti (CSM) solo back-end, progettato e creato esplicitamente come archivio dei contenuti che li rende accessibili tramite un’API per la visualizzazione su qualsiasi dispositivo.
Il front-end, sviluppato e gestito in modo indipendente, recupera il contenuto dal back-end headless tramite un’API di distribuzione dei contenuti, in genere in formato JSON. Ad esempio, potrebbe trattarsi di un’applicazione React o Angular (applicazione a pagina singola).
Un back-end CMS headless richiede in genere la struttura del contenuto, in base a un modello o a uno schema. Questo facilita le applicazioni client che richiedono il contenuto giusto per il rendering di un’esperienza. Alcuni CMS possono esporre contenuti strutturati e non strutturati in formato JSON.
Una caratteristica chiave di questa topologia è che il contenuto fornito dal CMS headless in formato JSON è contenuto puro, senza informazioni di progettazione o layout. In un’implementazione CMS headless, tutta la formattazione e il layout vengono mantenuti dall’applicazione front-end separata.
Un vantaggio chiave di una topologia CMS headless è la possibilità di riutilizzare i contenuti su più canali, che possono utilizzare implementazioni front-end lato client diverse. Ciò può rendere il processo di sviluppo del front-end più efficiente. Ma significa anche che il processo di sviluppo delle esperienze front-end può diventare molto orientato al codice e all’IT, a tal punto che sarà l’IT a gestire l’esperienza.
API per la distribuzione dei contenuti
Un CMS headless può fornire uno o più modi per esporre i contenuti ad applicazioni lato client. Nella maggior parte dei casi utilizza API REST HTTP, API GraphQL o entrambe.
Anche se un’API REST può spesso sembrare un modo più semplice di richiedere il contenuto (ad esempio, fornendo JSON per tutti i contenuti che corrispondono a un criterio), in genere consegna troppo contenuto a un’applicazione client. Questo può comportare la necessità da parte del client di analizzare e filtrare il contenuto effettivamente necessario per il rendering.
GraphQL, al contrario, si basa su un meccanismo più mirato che consente alle applicazioni client di richiedere esattamente il contenuto necessario per riprodurre un’esperienza.
CMS full-stack
Un CMS full-stack solitamente rappresenta la topologia tradizionale per la gestione e la distribuzione dei contenuti, includendo la tecnologia di back-end e front-end per la riproduzione delle esperienze. La distribuzione dei contenuti in CMS full-stack si verifica solitamente rispetto alle API di distribuzione dei contenuti interne. La funzionalità front-end è tipicamente specifica per il CMS full-stack. Questa combinazione di tecnologia front-end con back-end di contenuto offre il vantaggio chiave di consentire la creazione di esperienze WYSIWYG (What-you-see-is-what-you-get).