Headless is more (Parte 2/4)
Nell’articolo precedente è stata analizzata la differenza tra sistema monolitico ed architettura orientata ai microservizi. Uno dei sistemi monolitici più diffusi è il software che gestisce i contenuti di un sito web, ovvero il CMS.
Headless CMS
Headless, letteralmente senza testa, è un termine che fa riferimento ad una determinata tipologia di CMS, in cui c’è totale separazione tra gestione e presentazione dei contenuti.
Per capire in dettaglio quanto sia importante separare il contenuto dalla sua presentazione è utile fare un paragone con un modello strutturato molto diffuso in informatica: MVC.
Diversi framework utilizzano questo modello (es. Laravel, Symfony o Ruby on Rails), al fine di dividere ed organizzare le varie componenti utili alla realizzazione di un applicativo web:
• M = model fornisce i metodi per accedere ai dati utili dell’applicazione
• V = view visualizza i dati contenuti nel model e si occupa dell’interazione con utenti e agenti
• C = controller riceve i comandi dell’utente (in genere attraverso view) e li attua modificando lo stato degli altri due componenti
I CMS “tradizionali” forniscono tutte queste 3 componenti: infatti in questo modo si ha la possibilità di archiviare e modificare contenuti, di fruire delle funzionalità per interagire con gli stessi e di utilizzare i template per presentare i dati.
Questo, però, non significa che tutti i CMS implementino il modello MVC.
WordPress lascia ai programmatori totale libertà di accesso ai dati da qualunque parte dell’applicativo, anche direttamente da un template, creando grande confusione e disomogeneità (chiamato nel settore “spaghetti code”).
Nella pratica questo si traduce in una maggiore complessità nella gestione di progetti di grandi dimensioni. Inoltre la mancanza di standard si manifesta in particolare quando risulta necessario che team diversi visionino il progetto.
Così come MVC aiuta a migliorare l’organizzazione di un applicativo, Headless permette di migliorare la distribuzione dei contenuti presenti in un CMS, in particolare su progetti complessi e con molteplici touch point.
I 3 vantaggi dei CMS Headless
Multicanalità
Secondo una statistica condotta da Google nel 2017 ogni persona ha avuto in media 3.5 device connessi ad internet. Nel 2012 questo numero superava di poco i 2, questa tendenza quindi ci dice che in futuro ci saranno sempre più dispositivi connessi.
Questi dispositivi hanno schermi di dimensioni completamente diverse, alcuni sono addirittura privi di interfaccia visuale, come assistenti vocali e chatbot.
Pensare ad un CMS che fornisca contenuti limitandosi al sito web diventa sempre più riduttivo e porta così ad escludere canali più moderni e di tendenza.
Inoltre la gestione di questa moltitudine di flussi diventa molto più complessa se frammentata su più piattaforme. L’architettura headless supera queste problematiche proponendo una piattaforma unica per la gestione dei contenuti ed interfacce specifiche personalizzate per i diversi touch point.
Sicurezza
I CMS raccolgono sempre più contenuti di valore e sono esposti ad attacchi continui. Un’architettura monolitica rende molto più complessa la manutenzione e la correzione di eventuali bug. Spesso è proprio da malfunzionamenti presenti nelle interfacce che avvengono le intrusioni, come sql injections & cross site scripting. Grazie ad un CMS headless SaaS si vanno a minimizzare i rischi e ad aumentare sensibilmente la sicurezza di tutta l’infrastruttura. Questo ci permette di avere i dati al sicuro e di ridurre sforzi per attività legate all’appesantimento delle infrastrutture.
Performance e Scalabilità
Nei CMS tradizionali l’esecuzione delle interfacce è un’operazione molto onerosa per il server: spesso si cerca infatti di “staticizzare” pagine e/o frammenti di pagine attraverso sistemi di cache, che sono spesso complicati e possono generare bug ed inconsistenze.
L’erogazione esclusiva di API è chiaramente meno impegnativa a livello di gestione del problema, inoltre è possibile distribuire le API attraverso CDN, in modo da migliorare ancora di più la velocità di risposta (TTFB).
Nelle architetture headless l’esecuzione delle interfacce può essere delegata al cliente nel caso di app native o SPA, può essere invece implementata da altri server nel caso di applicazioni javascript isomorfe oppure venire completamento staticizzata nel caso di static site generation, una modalità di distribuzione delle interfacce che garantisce massime performance e sicurezza.
Un argomento strettamente collegato alle performance è la scalabilità. Con questo termine si intende generalmente la capacità di un software di mantenere buone prestazioni con l’aumentare del numero di utilizzatori o dati (scalabilità di carico) e della distanza fisica tra l’utente e il server (scalabilità geografica). Un CMS headless può scalare a livello di carico in quanto si presta molto bene ad essere incluso in soluzioni cloud SaaS. Inoltre la possibilità di distribuire le API attraverso CDN ci permette un’ottima diffusione a livello geografico.
Ma in quali ambienti di hosting un CMS può essere installato? Nel prossimo capitolo tratteremo anche questo argomento.
Non abbiamo ancora finito!
Headless is more (parte 1) — Differenza tra Monolite e Headless technology
Headless is more (parte 2) — CMS Headless e 3 vantaggi chiave
Headless is more (parte 3) — 5 Hosting per sviluppare la Headless technology
Headless is more (parte 4) — 3 scenari di sviluppo
Vuoi approfondire il tema dei device connessi?
Abbiamo trovato un’infografica che ti può dare un quadro generale:
🔗 the-internet-of-things-and-our-mobile-future/
