CMS tradizionale vs headless

Da qualche tempo si parla di CMS headless, un modello architetturale dove il Content Management System espone dati e funzionalità attraverso API o SDK. Quali sono i vantaggi reali per l'utente finale e per gli sviluppatori? Ne parliamo con Giacomo ed Andrea, developer di Moze.

Sergio Panagia

Partner, Technical Director

Giacomo Alonzi

Developer

Andrea Luconi

Developer

Ascolta su Apple PodcastsSpotify o Google Podcasts

Sergio Panagia: Benvenuti nel podcast di Moze, uno spazio di discussione e approfondimento tecnico sullo sviluppo di nuovi prodotti digitali. Io sono Sergio, partner dello studio, e con me oggi ci sono Giacomo e Andrea, developer di Moze. Ciao ragazzi.

Giacomo Alonzi e Andrea Luconi: Ciao a tutti.

Sergio: Tradizionalmente, un software CMS è concepito per accogliere sia il livello dati (database), sia il livello presentazione (il tema). È il caso dello sviluppo “tradizionale”, fatto utilizzando WordPress o Shopify. Da qualche tempo si parla anche di headless: il termine si riferisce ad un modello architetturale dove il Content Management System espone dati e funzionalità attraverso un API o un SDK. Il CMS non si occupa quindi di come questi dati vengono presentati. Dall’altra parte c’è un sito web, un’applicazione web o mobile dedicata a presentare questi dati. Nel modello Jamstack, in particolare, le informazioni vengono pre-generate (pre-render). Nel caso di un sito o applicazione web vengono generati file html, senza reperire cioè ad ogni richiesta le informazioni attraverso un linguaggio server-side e un database. Questi due principi, rispettivamente il pre-rendering e il decoupling (separation of concern) sono le fondamenta di questo approccio architetturale. Cosa cambia, in sostanza, Giacomo?

Giacomo: I benefici sono tempi di risposta più veloci (performance migliori), maggiore sicurezza by design (grazie al fatto che non c’è un database esposto) ma soprattutto la possibilità di costruire un’applicazione complessa, che reperisce cioè dati da più fonti (ad esempio, oltre al CMS, ad un CRM aziendale o ad altri endpoint API).

Sergio: Quali sono gli strumenti che si possono impiegare?

Giacomo: Lato CMS, ci sono alcune soluzioni “nate headless”, come Strapi e Sanity (CMS). Tuttavia è possibile usare soluzioni come WordPress in modalità headless. Lato front-end ci sono soluzioni come Next.js e Gatsby, ma nessuno ci vieta di poter adottare soluzioni custom, dipende da quello di cui si ha bisogno. In generale utilizzare framework già pensati per questa tipologia di soluzione semplifica di molto il lavoro di noi developer.

Sergio: Parliamo della nostra esperienza: Sanity, Next.js, Vercel. Cos’è Sanity? Quali sono i benefici rispetto ad un CMS tradizionale come WordPress?

Andrea: Sanity è un servizio che mette a disposizione un database in cloud e un CMS open source chiamato Sanity Studio. La particolarità di Sanity Studio è l’essere basato su React. Questo permette a noi developer di creare in piena libertà nuovi componenti che andranno poi a formare l’interfaccia per la gestione dei contenuti. Possiamo inoltre installare plugin messi a disposizione dalla community o crearli ex novo.

Sergio: L’editor dei contenuti è dunque completamente customizzabile, corretto?

Andrea: Esatto. Per aumentare il livello di customizzazione Sanity Studio, oltre ai componenti forniti di default, offre la possibilità di crearne di nuovi: i cosiddetti custom input component. Questi non sono altro che componenti React utilizzati, ad esempio, per creare interfacce custom, reperire dati da API di terze parti, mostrare preview direttamente nel campo di input, contribuendo a migliorare notevolmente l’esperienza utente di chi sta utilizzando il CMS. Sanity, inoltre, ci semplifica la creazione dei componenti mettendo a disposizione una libreria (Sanity UI) con elementi già pronti all’uso (pulsanti, select, card ecc…) e dei metodi (ad es. PatchEvent API) per poter scrivere direttamente nel dataset di Sanity in maniera molto semplice.

Sergio: In pratica, se un CMS deve interfacciarsi con dati di terze parti, magari in un servizio in cloud, Sanity può essere la soluzione giusta perché permette piena personalizzazione del processo di gestione dei contenuti, potendo comporre l’interfaccia e la logica di reperimento dati secondo necessità.

Sergio: Perché React? Cos’è Next.js e quali i benefici nel contesto headless?

Giacomo: React è una libreria di rendering sviluppata da Facebook e adottata dalla community che ha esteso le sue funzionalità con moltissimi pacchetti npm (ovvero librerie e componenti già pronti all’uso). Next.js è un framework basato su React, che mette a disposizione dei developer strumenti di lavoro per facilitare, ad esempio, la gestione del routing o il fetch delle informazioni. È una soluzione “plug and play” che non richiede particolari configurazioni se si ha bisogno di una soluzione standard. Ci fornisce strumenti come il pre-fetch, il pre-rendering statico o il pre-rendering server-side.

Sergio: Qual è la differenza tra questi metodi di rendering?

Giacomo: La generazione statica avviene nel momento di build, ovvero, quando facciamo il deploy del nostro sito i dati vengono richiesti alla fonte (che potrebbe essere un API o un file specifico) e vengono letteralmente scritti (iniettati) nell’html. Quindi, quando l’utente chiederà nuovamente la pagina, non verrà fatta nessuna chiamata lato server per reperire quei dati. L’esecuzione della pagina è quindi immediata e riduce a zero il rischio di esposizione di database non avendo in carico nessuna chiamata esterna per reperire i dati. Questo, oltre a migliorare notevolmente le performance, riduce anche i costi perché, non essendoci elaborazione server-side, quello che viene servito è essenzialmente un file statico: più facile da distribuire anche attraverso servizi di CDN che permettono la diffusione su scala globale. Il server-side rendering, invece, funziona in modo leggermente diverso: quando l’utente atterra sulla pagina, questa viene richiesta al server con specifici parametri (magari dinamici, es. l’id di un prodotto in un e-commerce). Il server farà la chiamata ad un API per reperire le informazioni basate sul parametro che verrà richiesto, farà la build (quindi scriverà le informazioni specifiche di quella pagina nel file html statico) di quella specifica richiesta e servirà il file statico all’utente. È una tecnica necessaria quando si ha bisogno di indicizzare il contenuto di una pagina con dati dinamici.

Sergio: Altrimenti ci sarebbe il rischio di rendere i contenuti indicizzabili.

Giacomo: Esatto. Next mette a disposizione strumenti molto semplici per raggiungere questo risultato e permette anche un uso ibrido degli stessi strumenti: è possibile, infatti, specificare il tipo di pre-rendering da utilizzare sulle singole pagine.

Sergio: Grazie Giacomo. Andrea, cos’è Vercel? E cosa lo rende interessante?

Andrea: Vercel è una piattaforma adatta al deploy di applicazioni front-end sviluppate con framework (come React o Next.js) e di siti statici. Si sposa perfettamente con Next.js, creato proprio dagli sviluppatori di Vercel. La possibilità di collegare direttamente il repository alla piattaforma rende particolarmente facile, per il team di sviluppo, fare il deploy dell’applicazione. Abbiamo trovato molto utile la funzionalità “Preview”, che consente di vedere rapidamente il risultato di qualsiasi contributo al codice sorgente, anche su branch diverse da quelle principali. Con Vercel, è possibile inoltre far uso di funzioni serverless. Si tratta di un paradigma architetturale in cui determinate porzioni di codice vengono eseguite da un provider Cloud, evitando le principali problematiche di setup, deploy e gestione di server. Abbiamo sperimentato questa funzionalità sia in Next.js, in maniera molto semplice grazie alla preconfigurazione dello stesso framework per questo tipo di servizio, delegando alle funzioni serverless di Vercel determinati compiti: ad esempio la generazione di PDF e, in Sanity Studio, la possibilità di visualizzare in tempo reale i cambiamenti apportati ad una pagina, migliorando l’esperienza degli utenti editor.

Sergio: Grazie Andrea. Giacomo, quando scegliere headless? Quando invece optare per una soluzione più tradizionale?

Giacomo: Questo dipende dal progetto, se parliamo di applicazioni custom una scelta di design di questo tipo non esclude il poter utilizzare approcci più tradizionali nello sviluppo di applicazioni. Ad esempio potrei avere delle parti della mia applicazione con pre-rendering statico, parti con server-side rendering e in entrambe le parti potrei avere chiamate api in real time. Questo dipende dall’obiettivo che si desidera raggiungere. Una scelta headless è in grado di fornire i contenuti che possono essere usati sostanzialmente da qualsiasi client, dispositivo e linguaggio. Questa flessibilità consente di prendere le decisioni tecnologiche più adatte per il tipo di applicazione di ciascuna situazione, un esempio su tutti è quando si deve sviluppare un prodotto digitale con un client web e uno mobile. In questo senso, una soluzione headless è agnostica rispetto al tipo di front-end 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. Questa scelta può rendere più facile decidere di cambiare piattaforma di gestione contenuti in un secondo momento, ma soprattutto migliora la scalabilità del progetto, soprattutto quando il client che lo consuma è un’applicazione JavaScript come ad esempio un’applicazione basata su Next.js.

Sergio: Grazie Giacomo e grazie Andrea. Oggi abbiamo parlato di headless, di Jamstack e di quanto può avere senso applicare un paradigma architetturale di questo tipo. Siamo curiosi di ascoltare altre esperienza. Scriveteci su www.mozestudio.com. Grazie Giacomo e grazie Andrea!

Giacomo e Andrea: Ciao!




    Premi INVIO

    Procedi

    premi INVIO

    Grazie

    Ti contatteremo presto.