Come l'architettura "headless" sta rivoluzionando il mondo tech
tl;dr

Il termine “headless” ultimamente è sulla bocca degli addetti ai lavori del panorama tecnologico italiano e mondiale, a volte dimenticando che è un termine nato con la nascita stessa dei primi server/pc/sistemi integrati. I software headless sono infatti tutti quegli applicativi che non hanno una GUI (graphical user interface) e che quindi ricevono dati in input attraverso network o porte seriali. Al giorno d’oggi invece, parlando di headless, intendiamo principalmente Headless CMS, siti web headless o Decoupled frameworks. Ma perché se ne parla così tanto? In questo articolo ti spieghiamo cosa è “headless” e quali vantaggi può portare al tuo business questa architettura.

Il mondo del software è sempre più improntato a fornire la migliore esperienza possibile a utenti (e sviluppatori), che si traduce spesso in maggiori conversioni, tempi di sviluppo più brevi e flussi di lavoro più agili. È forse proprio questa la “spinta” su cui viaggia il trend dello sviluppo headless, che permette di isolare gli sforzi dei team di sviluppo in applicazioni e servizi singoli e indipendenti tra loro.

C’era una volta il software monolitico

In principio tutto (o quasi) era monolitico: il software che gestiva la fatturazione di un’azienda, ad esempio, era un unico blocco di funzionalità e servizi interdipendenti e quindi connessi tra loro. Non era possibile aggiornare e portare in produzione una singola parte di esso senza ricostruire l’intero applicativo, ed era anche altrettanto facile introdurre bug che influenzavano l’intero software, magari "crashando" tutto l’applicativo.

Inoltre, all’aumentare delle features è ridotta nel team di sviluppo la conoscenza dell’intero flusso del software. Questa frammentazione della conoscenza introduce colli di bottiglia all’interno del team stesso, con il classico esempio in cui lo sviluppatore X non può lavorare su una particolare feature senza sentire lo sviluppatore Y che ne è il creatore.

Insomma, con una prospettiva così le architetture monolitiche sembrano una cosa da evitare come la peste... e invece no!
Monolitico vuol dire anche (ma non solo) tempi di sviluppo più brevi, grazie al fatto che l’intero software è costruito tutto con le stessa tecnologia. Gli applicativi monolitici sono ancora oggi uno dei metodi più veloci per sviluppare applicazioni semplici che non saranno aggiornate molto spesso, e che quindi non sono soggette a cambiamenti continui.
Tutto questo si traduce in un vantaggio per l’intera azienda, che deve attingere a sviluppatori dello stesso “tipo” (mentre oggi cerchiamo sempre più “sviluppatori del terzo tipo”, alieni in grado di saper fare qualsiasi cosa), processi di onboarding più semplici e produttività più alte.

Che è ‘sto headless? Se magna?

Le soluzioni headless “spezzettano”, o meglio disaccoppiano, il software su cui opera il tuo business, separando i vari layer di cui sono composti i software monolitici.

In un ecommerce monolitico abbiamo generalmente tre layer: il layer di presentazione (quello che vedono i vostri clienti), il layer di business logic (tutte le implementazioni necessarie per gestire carrello, prodotti e pagamenti) e il data layer (come il vostro ecommerce comunica con il database). Questi tre layer sono schiacciati tra loro come una lasagna, si parla infatti di Lasagna Code.

Nei software headless questi layer sono invece separati tra loro e il mondo dei programmatori, avendo una particolare affezione per la pasta, li chiama Ravioli Code. Visto che siamo nel 2022, ed adesso più che mai un’immagine vale più di mille parole, eccone una che ben descrive queste architetture.

Il Ravioli Code, più propriamente usato in questo caso per i microservizi che per le architetture headless, separa i layer della lasagna in singole parti, i ravioli appunto.

Questo permette agli sviluppatori di creare servizi che comunicano tra loro ma che sono indipendenti, in cui è possibile aggiornare il layer di presentazione —che ricordiamo, è quello che vedono i vostri clienti— indipendentemente dal layer di business logic.

L’ecommerce di turno stavolta non sarà un unico pezzo di codice che vive su Github ed è deployato “tutto insieme” su un server, bensì sarà diviso in più parti:

  • Frontend: un sito statico, sviluppato usando un SSG, un generatore di siti statici, che magari potrebbe essere Gatsby o NextJS, le nostre tecnologie preferite per creare fantastici frontend, leggasi presentation layer, o “Quello che vedono i vostri clienti”, oppure il sito su cui siete adesso!

  • Headless CMS: un gestore di contenuti senza alcun frontend, utilizzato per realizzare le pagine statiche del vostro negozio online, come l’intramontabile “Chi siamo” o l’irrinunciabile “Contattaci”. Potremmo suggerirvi Contentful, Sanity o DatoCMS ad esempio.

  • Headless ecommerce: il “cuore” pulsante del vostro store, in cui gestite i prodotti, le promozioni, i pagamenti e tutto la business logic di un ecommerce tradizionale. Insomma: il backend! A noi piace molto Saleor, ma abbiamo utilizzato o provato il 99% delle soluzioni headless sul mercato.


Stiamo aggiungendo complessità? Probabilmente si. È così complesso come sembra? Probabilmente no. In sostanza il frontend, al momento della build (lo step in cui l’SSG compone il sito statico) interroga il backend chiedendo tutti i prodotti, con i loro dettagli e prezzi, e genera una pagina per ognuno di essi. La stessa cosa è ripetuta per le categorie, l’homepage, e ogni altra risorsa necessaria a costruire il vostro layer di presentazione.
Generate tutte queste pagine è la volta delle pagine “statiche”, come “Chi siamo” o “Contatti”: invece che interrogare il backend, stavolta interrogheremo il CMS, recupereremo i dati di ogni pagina e ne creeremo un output sotto forma di HTML, CSS e Javascript.

In pratica, facciamo la stessa cosa che fanno i software monolitici ma la facciamo separatamente e generandone un output “statico”. A questo punto, immagino che ti starai chiedendo perché utilizzare soluzioni headless per il tuo business, se alla fine cambia solo l’architettura?

Perché headless (a volte) è meglio?

Perché possiamo accedere a un mondo di performance praticamente senza pari.

Essendo il frontend generato staticamente, quando il vostro cliente preferito, che da ora in poi chiameremo Paolo, atterrerà su iltuoecommerce.it non ci sarà alcun tempo di caricamento (o quasi). Il tuo sito infatti è stato “prodotto” staticamente, ossia sono stati generati i file html, js e css già ottimizzati, pagina per pagina. Quando Paolo clicca sul vostro prodotto di punta non dovrà aspettare che il frontend chieda al backend se può passargli la foto, il nome e il prezzo del prodotto: questo sarà già li ad aspettarlo, pronto per essere aggiunto al carrello.

Questo si riflette inoltre in Web Vitals migliori, quindi tempi di caricamento più bassi, di conseguenza otteniamo posizionamenti migliori sulle SERP e una migliore esperienza di acquisto, o anche semplicemente di navigazione del vostro cliente.


💡 Gli Web Vitals sono metriche che misurano l‘esperienza dell’utente su un sito, sono un’iniziativa di Google volta a dare delle linee guida per costruire siti web accessibili, rapidi e che forniscano la miglior esperienza di navigazione possibile.

Perché abbiamo infinite possibilità di personalizzazione.

Staccando il sito visualizzato dagli utenti (layer di presentazione, o frontend) dal cuore del vostro ecommerce (layer di business logic, o backend) ci liberiamo dai vincoli imposti dalla piattaforma —o dal team di backend 😛— su cui stiamo lavorando. Possiamo finalmente mettere quei blocchi disallineati tutti in diagonale che l’Elementor o il Woocommerce di turno ci impedivano di creare.

Ma siamo anche pronti a creare promozioni particolari, features che non potevamo implementare se non “piegando” il software, integrazioni con servizi esterni che spesso sono dipendenti da plugin non aggiornati, non compatibili o che, a forza di aggiungerne, hanno fatto diventare il vostro sito un pachiderma di 6 tonnellate che impiega 15 secondi a caricare l’homepage.
Tutto questo mantenendo le performance del capitolo precedente, sembra quasi un sogno no?

Perché possiamo finalmente creare vere strategie omni-channel.

Una strategia omni-channel è il metodo con il quale promuoviamo il tuo business, un tuo prodotto o servizio su tutti i canali su cui i tuoi utenti interagiscono, creando un’esperienza di comunicazione coerente tra i canali, e maggiormente fruibile.

Grazie alle soluzioni headless possiamo evitare il problema dei data silos: i tuoi dati adesso risiedono in unico database e possiamo consumarli su più frontend (ricordi? i layer di presentazione!), che essi siano applicazioni mobile iOS, Android, siti web è indifferente, i tuoi dati adesso sono in unico database e vengono “serviti” dal tuo backend, il layer di business logic. Questo si riflette in un’esperienza uniforme su tutti i touch point con i tuoi clienti, e in un’esperienza del tutto stravolta, in meglio, per te e per i tuoi colleghi che ci lavorano ogni giorno e devono modificare qualcosa in troppi punti differenti.

Leggendo questo articolo sembra quasi che non ci siano contro all’utilizzo dei software headless, ma in realtà, come ogni strumento nel mondo tech, è solo un mezzo per raggiungere un fine.

Headless ha anche dei difetti

Lo sviluppo headless alza leggermente l’asticella della complessità architettonica, dovendo gestire più parti che si interfacciano tra loro. Questo richiede una maggiore comprensione di networking, spesso containers (come Docker, leggi qui se pensi sia il gruppo rock del momento -rimanda ad articolo), storage utilizzati per gestire gli asset del sito web come S3 o simili.

Minore, ma comunque da citare, il problema amministrativo: mentre nel software monolitico era da rendicontare lo sviluppo e il server che hostava l’applicativo, qui abbiamo

  • CMS, che spesso ha però piani gratuiti con funzionalità ridotte

  • Hosting del frontend: Cloudflare Pages, AWS S3 in combinazione con Cloudfront, Netlify e simili, con la precisazione che i costi in questo caso sono bassissimi nella maggior parte dei casi

  • Hosting del backend: una VPS, AWS ECS/Fargate/EKS e in generale servizi Cloud

  • Hosting degli asset via CDN: le foto dei prodotti, delle categorie e affini possono essere serviti dal vostro backend, ma è buona norma utilizzare una piattaforma terza detta Content Delivery Network, come AWS S3, Cloudflare R2, Backblaze o simili. Molti Headless CMS ne forniscono una integrata.


Abbiamo però una bella notizia per te: Trame Digitali ha puntato su questa tecnologia già molti anni fa, quando eravamo 4 colleghi in una piccola stanza.
Ci è sempre piaciuto sperimentare con tecnologie nuove, “cutting-edge” come si dice in gergo nerd, e quando ci siamo imbattuti in alcune soluzioni headless abbiamo intravisto delle potenzialità che avrebbero potuto stravolgere il mercato. E cosi è stato.

Headless è la “buzzword” del momento, ma si tratta davvero di una soluzione reale per le strategie digitali del futuro. E te, che aspetti ad immergerti nel futuro con noi?

Volevi leggerne altri vero? Eccoli!
Resta in ascolto che c'è un messaggio per te!
Agenzia
Servizi
Lavori
Jobs
Trame Digitali® è un marchio registrato da Nexha SRL, Via Frà Bartolomeo 82/A, Prato. P.Iva: 02450300971 - Credits
two hands tied with a red line