hero

Headless CMS

Headless CMS, il nuovo approccio architetturale

Con l’approccio headless cms, e il relativo disaccoppiamento completo tra sviluppo front-end e servizi di back-end, è possibile utilizzare piattaforme di CMS in modo molto flessibile, agile e scalabile.

In questo modo si ha il vantaggio di mantenere la parte redazionale e di back-end invariata, con grande felicità dei redattori che non dovranno cambiare metodo di editing dei contenuti, ma allo stesso tempo permette di avere un front-end multichannel senza legacy di prodotto o tecnologia e con elevatissime performance e sicurezza.

Cosa sono i CMS Headless

Per chi ha particolari esigenze di sicurezza, performance e scalabilità, Ariadne propone un nuovo approccio architetturale (JAMStack) che comporta l’utilizzo del proprio CMS (Liferay, WordPress, Contentful, etc) come un Headless CMS insieme a Gatsby.

Dopo tanti anni, abbiamo abbandonato l'utilizzo di CMS tradizionali orientandoci verso un’architettura JAMStack. I motivi che ci hanno portato a proporre questa scelta sono molteplici, sia di natura tecnologica, sia tenendo conto delle prospettive future.

Gatsby è un generatore di siti statici fortemente orientato alle prestazioni tanto da seguire il pattern architetturale PRPL, inoltre è basato su tecnologie considerate di frontiera quali React e GraphQL. In altre parole, iniziare oggi ad utilizzare Gatsby dà la possibilità di confrontarsi con gli aspetti più moderni del web.

Inoltre, adottare questa soluzione è il primo passo verso un’architettura serverless nella quale il contenuto stesso può essere visto come servizio.

JAM è un acronimo per Javascript API Markup, non è un framework ma un approccio architetturale i cui principali obiettivi sono: sicurezza, performance, scalabilità e completo disaccoppiamento tra sviluppo frot-end e servizi di back-end.

Uno dei concetti chiave di un'architettura JAM è il ritorno al sito "statico", ovvero l'intero sito viene rigenerato (fase di build) ogni volta che avviene un cambiamento e pubblicato tramite CDN. Attenzione che statico non implica limitazioni nell'interazione utente, ma solamente che i file HTML/JS/CSS sono file statici. I file javascript una volta caricati sul client possono interagire con altri servizi rispondendo a qualunque esigenza funzionale (form, ricerche, login, e-commerce, ecc...).

Evolution web

Come funzionano i CMS Headless

Un sito semi-statico

La parte "dinamica" dell'architettura viene usata principalmente dai redattori per inserire contenuti (per esempio con cadenza settimanale), per il resto del tempo le pagine sono sempre le stesse. In uno scenario come questo è sufficiente garantire:

  • un'interfaccia redazionale per la gestione dei contenuti
  • un processo che, a fronte di una richiesta di pubblicazione, generi automaticamente le pagine statiche da pubblicare sul CDN
  • poter visionare una preview prima della pubblicazione .
  • un form per la raccolta dei contatti/richieste

La gestione dei contenuti

Considerate dunque queste esigenze, la soluzione proposta è l'impiego di un Headless CMS. Esistono diversi tipologie di Headless CMS gli stessi Wordpress e Drupal (Contenta) possono essere usati in questo modo, noi per gli ultimi progetti realizzati abbiamo scelto Contentful, vista l’esigenza di avere un'architettura serverless. Provare Contentful è stata anche l’occasione per sperimentare quale impatto avrebbe avuto sui redattori un diverso approccio alla redazione dei contenuti: nello specifico davanti a Contenful il redattore deve concentrarsi solo sul contenuto, senza pensare al contesto in cui questo verrà presentato. Oltre all’ottima usabilità dell’interfaccia, tra le funzionalità di Contentful che abbiamo apprezzato maggiomente ci sono: le Media Asset API per la gestione lato front-end delle immagini responsive, il multi-environments (sandbox) e la gestione del multilinguismo.

Static Site Generator

Sono ormai cinque anni che in Ariadne utilizziamo gli SSG (Assemble) per la realizzazione di prototipi da condividere e testare con i clienti. Ancora oggi siamo convinti che per il rapid prototyping qualunque SSG sia una valido strumento ma, per un sito il cui ciclo di vita non termina con la prototipazione, abbiamo individuato in Gatsby la nostra soluzione ideale.

Gatsby

I motivi che ci hanno portato a questa scelta sono molteplici, sia di natura tecnologica, sia tenendo conto delle prospettive future. .

Gatsby è fortemente orientato alle prestazioni tanto da seguire il pattern architetturale PRPL, inoltre è basato su tecnologie considerate di frontiera quali React e GraphQL. In altre parole acquisire conoscenza in Gatsby vuol dire confrontarsi con gli aspetti più moderni del web. Gatsby negli ultimi anni ha raccolto molti finanziamenti e presenta una community in continua crescita, sicuramente non è un progetto destinato a scomparire, anzi siamo convinti che con il crescere delle metodologie JAMstack il suo ruolo sarà sempre più centrale.

La nostra soluzione serverless con Contentful e AWS

Entriamo più nello specifico e analizziamo come queste componenti interagiscono tra loro. In altre parole: Come possiamo pilotare l’evento di generazione del sito (build)? Dove viene eseguito il build? Come pubblicare il codice generato?

Per rispondere a queste domante abbiamo valutato e testato due alternative:

  1. Utilizzare AWS CodePipeline e AWS CodeBuild.
  2. Dotarsi di un server ad uso interno in grado di:

    a. Esporre l’endpoint (tramite un pagina di amministrazione)
    b. Eseguire il build
    c. Esporre internamente la versione generata (sito di stage)
    d. Sincronizzare il CDN (Bucket S3 di AWS)

schema architetturale

Integrazione di servizi – il form contatti

Il form di contatti è gestito tramite AWS e più precisamente coinvolge le seguente componenti:

  1. API Gateway: endpoint per l’invio del form
  2. Lambda Functions: racchiude il codice che processa la richiesta
  3. SES (Simple Email Service) è il servizio di Amazon usato per inviare l’email di notifica
  4. DynamoDB è il database non relazionale in cui vengono salvate le risposte del Form

aws serverless

Headless CMS quali sono i vantaggi?

Ecco quali sono secondo noi i principali punti di forza di questa soluzione:

  • Elevate performance
  • Sicurezza
  • Costi di erogazione / manutenzione ridotti
  • Possibilità di mantenere uno storico dei rilasci e rapidità nel recupero di uno stato precedente
  • Disaccoppiamento dei contenuti dallo sviluppo front-end, che si traduce nell’assenza di vincoli tecnologici e nella parallelizzazione dei processi di sviluppo.
  • Tempi di sviluppo e rilascio molto brevi, ideale per mercati in cui le iniziative di comunicazione digitale sono molte e frequenti.

E il punti deboli?

  • lo svantaggio principale è il tempo di attesa dovuto al build (anche se mediamente si aggira tra i 3-5 minuti)
  • la realizzazione di componenti "applicative", spesso già presenti nei CMS tradizionali sotto forma di moduli/plugin, può presentare un costo di implementazione non trascurabile.

In conclusione ci sentiamo di dire che la scelta è sicuramente vincente quando:

  • sicurezza e perfomance sono veramente aspetti critici e non solo dei desiderata (tutti ovviamente vorrebbero avere siti sicure e veloci)
  • quando le attività redazionali sono più simili al data entry che non alla gestione del sito inteso come architettura informativa.
  • si vuole costruire un'architettura serverless il cui il contenuto è visto come servizio e il sito è solo uno dei canali di comunicazione.

Contattaci

Vuoi che il tuo progetto sia un successo? Scrivici per raccontarci le tue esigenze e trovare insieme la soluzione migliore!

Nome e cognome *
Azienda *
Email *
Telefono
Messaggio *

Le nostre certificazioni