
Indice dell'articolo
TLTR
Ci sono diversi approcci all’architettura di un sito o di un’applicazione web. Una delle soluzioni emergenti si chiama Jamstack, e presenta delle caratteristiche molto specifiche (disaccoppiamento delle funzioni, pre-rendering dei contenuti, modularità, GIT-based e versionamento) che portano a grandi vantaggi in termini di performance, sicurezza, scalabilità ed economicità.
L’approccio Jamstack ha come principale controindicazione il fatto di necessitare di più lavoro (tempi e costi) rispetto a soluzioni preconfezionate, e di essere quindi una soluzione adatta solo a chi cerca qualità e prestazioni.
Introduzione
In un articolo recente, abbiamo parlato di come un nostro sito abbia totalizzato il miglior punteggio possibile su web.dev/measure, lo strumento ufficiale di Google per la misurazione delle performance di un sito web.
Per il sito citato, falegnameriamuraro.it, abbiamo implementato un’innovativa architettura web denominata Jamstack, utilizzando un framework Javascript chiamato Svelte *.
In questo articolo vogliamo descrivere le scelte tecnologiche che abbiamo adottato, con lo scopo di illustrare, e auspicabilmente rendere comprensibili, le differenze, i vantaggi e gli svantaggi rispetto alle soluzioni più note e consuete.
* Per questo progetto lo stack si completa con Tailwind CSS per lo styling, Netlify CMS come headless CMS e Vercel per il deploy.
L’architettura Jamstack
Alla base di tutto c’è una nuova modalità, un nuovo paradigma per la realizzazione di siti e applicazioni web, che è stato battezzato Jamstack (originariamente JAMstack). A dargli questo nome è stato Mathias Biilmann, CEO e fondatore di Netlify: azienda che fornisce servizi di cloud computing finalizzati all’impiego di queste tecnologie. Ecco la sua definizione di Jamstack:
“A modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup”.
Mathias Biilman
Jamstack non è dunque un linguaggio, non è un framework e non è un tool. È un approccio all’architettura web, che poggia su queste tre colonne:
- JavaScript
- APIs
- Markup
Javascript
Tutte le funzionalità dinamiche sono gestite attraverso Javascript: il linguaggio di programmazione del web, in una delle sue diverse forme e declinazioni, librerie e framework possibili.
API
Tutte le funzionalità lato server sono astratte e incapsulate dentro API riutilizzabili. Si tratta, in estrema sintesi, di procedure standardizzate che permettono a un’applicazione software di integrarsi e dialogare in modo facile, sicuro ed efficiente con altre applicazioni.
Markup
L’architettura Jamstack si basa sui contenuti HyperText Markup Language, lo standard web, serviti in semplici file statici che vengono distribuiti nella rete nel modo più veloce ed efficiente possibile, attraverso un Content Delivery Network (CDN).
Principi e caratteristiche
Procediamo ora con una panoramica delle caratteristiche salienti dell’architettura Jamstack. Non è facile parlare in modo sintetico e semplice di argomenti complessi ma ci proviamo, per dare almeno un’idea delle differenze salienti rispetto agli approcci classici.
Disaccoppiamento delle funzioni
Nel 2021 la maggior parte dei siti web è realizzata attraverso un CMS come WordPress, o un site builder come Wix. In entrambi i casi il codice, i contenuti e il design sono gestiti da un unico sistema, un’unica, complessa applicazione monolitica.
Il “motore” è nel backend, dove risiedono la logica e il codice di funzionamento di tutta l’applicazione, e dove vengono inseriti i template. Nel backend vi è anche un CMS (Content Management System), con cui vengono creati e gestiti i contenuti, che vengono archiviati nel database di un server.
Quando gli utenti accedono alle pagine del sito, i contenuti necessari vengono pescati dal database, vengono assemblati nei template e serviti nel browser.
In un’applicazione Jamstack invece, tutti questi processi vengono disaccoppiati e gestiti separatamente, da applicazioni specializzate e indipendenti. Questo approccio offre anche un’estrema flessibilità e libertà tecnologica, rendendo possibile sostituire con relativa facilità i diversi elementi del sistema, componendo secondo necessità diversi stack tecnologici.
Pre-rendering dei contenuti
In un sito Jamstack, tutto il frontend (ciò che di un sito è visibile agli utenti e viene mostrato nel browser) è costruito in anticipo rispetto alle richieste degli utenti: i contenuti sono sempre pronti per essere serviti nella forma di pagine statiche altamente ottimizzate.
Anche con un CMS tradizionale c’è la possibilità di fare il pre-cache dei contenuti, che, per molti aspetti ed entro certi limiti, funziona come il pre-rendering di un’architettura Jamstack. Al di là dell’eventuale superiorità di una soluzione rispetto all’altra, la logica di funzionamento sottostante resta diametralmente opposta:
- un CMS è un’applicazione dinamica che può preparare in anticipo i contenuti statici (pre-cache);
- Un sito Jamstack è un’applicazione statica che è in grado di fare tutte le necessarie chiamate dinamiche.
In un sito basato su un CMS tradizionale il grosso del lavoro viene svolto nel backend, lato server. In un’applicazione Jamstack invece, il baricentro si sposta quasi interamente nel frontend, direttamente nel browser usato dall’utente, da cui partono le richieste per ogni forma di dato dinamico: quando necessario, solo se necessario.
Modularità
La fondamentale modularità dell’approccio Jamstack permette di collegarsi virtualmente, via API, a qualsiasi tipo di servizio. Questo permette, da un lato, di non dover reinventare la ruota ogni volta che ne serve una e, dall’altro, di poter costruire applicazioni estremamente complesse, integrandole con relativa facilità con servizi specializzati o evoluti.
GIT based e versionamento
Una delle caratteristiche di Jamstack che spesso si scorda di citare è il fatto che si basa su GIT.
Cos’è GIT? GIT è probabilmente il più importante strumento di lavoro degli sviluppatori software.
Si tratta di un rigoroso e potente sistema di controllo di versione, che permette di tenere traccia di tutte le modifiche apportate ai file sorgente nel corso del tempo. È uno strumento utilissimo nei piccoli progetti e indispensabile nei progetti complessi, lì dove molte persone lavorano assieme in modo asincrono e non lineare.
Giusto come nota di colore, aggiungiamo che GIT è stato realizzato, pare in solo un paio di giorni e di notti di lavoro (!!!), da Linus Torvalds, il controverso e geniale padre di Linux.
Grazie a GIT, tutto il codice sorgente di un sito o di un’applicazione Jamstack viene salvato su servizi di repository online quali Github, Bitbucket, Sourceforge in modo facile, veloce e sicuro.
Il risultato è che con pochi brevi comandi, uno sviluppatore può salvare il suo lavoro nel cloud, un collega può scaricarlo nel suo computer, condividerlo con altri colleghi, confrontare versioni del codice realizzate in momenti diversi, ripristinare versioni precedenti (!!!), e molto altro ancora.
I vantaggi di Jamstack
Ora che ci siamo fatti un’idea su cosa sia e su come funzioni l’architettura Jamstack, vediamo la cosa più importante e più interessante: quali sono i vantaggi di questo approccio. Alcuni li abbiamo già anticipati e sono la diretta conseguenza delle caratteristiche che abbiamo appena visto.
Prestazioni
Nell’architettura Jamstack, i contenuti sono già pronti all’uso (pre-rendered) e già distribuiti in tutta la rete attraverso una CDN (Content Delivery Network). Dal punto di vista della velocità, questa è la migliore soluzione tecnologica oggi disponibile.
Per rendere l’idea della differenza rispetto a un sito realizzato in modo tradizionale con un CMS, proviamo a fare un confronto utilizzando una metafora.
Immaginiamo quindi che sia
- un lettore (un utente web) che si reca in libreria (il browser del suo computer o del suo smartphone)
- per ordinare un testo (digiti cioè l’url di una pagina web)
- che non è già disponibile in libreria (non è nella cache del suo browser).
Vediamo cosa succede nei due diversi scenari.
| La libreria (il browser) inoltra la richiesta al suo grossista (nodo di rete). | La libreria (il browser) inoltra la richiesta al suo grossista (nodo di rete). |
| Il grossista inoltra la richiesta alla casa editrice (il server che ospita il sito). | Il grossista ha già in casa una copia stampata del testo che consegna immediatamente alla libreria (il contenuto era pre-renderizzato e già distribuito in rete attraverso CDN). |
| La richiesta viene smistata al reparto di stampa (il CMS), | |
| in cui un operatore recupera le matrici del documento dal magazzino (database). | |
| Il documento viene quindi stampato (rendering del contenuto nel template), | |
| e consegnato a uno spedizioniere (server di rete), | |
| che lo spedisce al grossista (nodo di rete), | |
| che infine lo recapita alla libreria (il browser dell’utente). |
Questa metafora, seppur grossolana e approssimativa, ci aiuta a capire le ragioni per cui ci sono (pochi) siti che si caricano e diventano interattivi in un paio di secondi, e (molti) altri che richiedono una decina di secondi o anche di più.
Come altri professionisti (non tanti a dire il vero), anche noi di Antartika da molti anni stiamo affrontando con impegno il tema delle performance e, anche per i siti che realizziamo su CMS “tradizionali” (tipo WordPress per intenderci), offriamo soluzioni evolute e performanti, quali il pre-caching dei contenuti e la distribuzione con CDN. Ma non è così, purtroppo, per la stragrande maggioranza dei siti web attualmente in rete.
Sicurezza
Un’applicazione Jamstack espone pubblicamente soprattutto contenuti statici che, in quanto tali, non presentano vulnerabilità. Accanto agli asset statici restano esposti, come possibili punti di attacco, solo le API dei microservizi dinamici: pochi e facilmente controllabili (per esempio con implementazioni read-only, tutte le volte che sono possibili). Tutt’altra cosa quindi rispetto a un classico CMS monolitico, in cui tutte le varie funzioni dinamiche (della core application del CMS, del template, dei plugin) costituiscono elementi di vulnerabilità e possibili punti di attacco.
In estrema sintesi: i fattori di rischio e vulnerabilità di questa architettura risiedono quasi esclusivamente nel fattore umano, nelle password e nei processi di autenticazione dei microservizi: con una gestione rigorosa di questi aspetti si può raggiungere un livello di sicurezza con pochi paragoni (senza dimenticare però che la sicurezza assoluta purtroppo non esiste e che qualsiasi servizio connesso in rete non può resistere a un attacco condotto con potenza tendente a infinito e/o per una durata tendente a infinito).
Economicità di funzionamento
Per prima cosa, come dicevamo sopra, l’architettura Jamstack sposta gran parte del lavoro dal backend al frontend, dal server al browser. Questo ha anche un’importante conseguenza economica, che ora vediamo. Nel processo di creazione e consumo di un contenuto nella rete, ci sono infatti due costi:
- il costo a carico della piattaforma che ospita e pubblica il contenuto (server ed energia che consumano)
- il costo a carico dell’utente che utilizza il contenuto (dispositivo ed energia che lo alimenta).
Quindi, spostare buona parte del lavoro dal server ai client degli utenti, significa anche spostare una larga parte dei costi su questi ultimi (per il singolo utente si tratta di costi così bassi che solitamente, almeno nelle aree più fortunate e ricche del mondo, non sono nemmeno percepiti né considerati).
Secondariamente, l’architettura Jamstack, per quanto già spiegato, riduce al minimo il numero di scambi (chiamate e risposte) e la quantità di informazioni trasferite tra server e client (riducendo quindi le risorse e l’energia necessaria).
Come terza e ultima considerazione aggiungiamo anche che l’adozione di questo approccio, da parte degli sviluppatori, nasce solitamente da una grande attenzione alle performance, quindi alla velocità e alla leggerezza del codice. Anche questo si traduce in un minor impiego di hardware e di energia.
Per questi tre fattori appena citati, possiamo legittimamente pensare che l’architettura Jamstack possa avere dei costi di gestione concorrenziali rispetto alle soluzioni tradizionali. Anche se i player specializzati in questi servizi di hosting sono ancora molto pochi, pare comunque che i prezzi offerti siano assolutamente accessibili, e molti fornitori offrono anche un generoso free tier, che può essere sufficiente per molti piccoli business.
Scalabilità
Basandosi su GIT, con contenuti statici e microservizi, bastano due click e poco più per fare il deploy su uno dei vari servizi di cloud computing specializzati nell’architettura Jamstack (Netlify, Vercel, Gatsby Cloud, ecc.).
E tutto lo sforzo per mettere a punto la propria strategia di content delivery, anche per applicazioni complesse, è già finito qui: può essere facilmente ed economicamente esternalizzato a uno di questi fornitori specializzati. E al crescere delle risorse necessarie, con altri due click si fa l’upgrade verso il livello di servizio superiore.
Controindicazioni: costi
Il fatto che si tratti di una soluzione completamente custom made presenta degli ovvi vantaggi ma altrettanto evidenti svantaggi: a differenza di un sito WIX o di un sito WordPress realizzato con un template standard, non si tratta infatti di una soluzione pronta, che funziona “out of the box”.
L’architettura Jamstack va pensata e progettata caso per caso, in termini di personalizzazione dei servizi sulla base delle specifiche necessità. Ci sono tante domande a cui seguono risposte e scelte tecnologiche molto diverse. Per esempio:
- Conviene utilizzare un framework Javascript? Se sì, quale? React? Vue? Angular? Svelte?…
- Serve un site generator come Next, Hugo, Gatsby, Jeckyll, Nuxt…?…
- Per lo styling cosa si usa? Tailwind? Styled Components? CSS Modules?…
- Serve un CMS? Quale scegliere tra le decine di possibilità: Strapi? Ghost? Contentful?…
- Che hosting usare? Netlify? Vercel? Heroku? AWS?
- ecc.
Scegliere lo stack giusto è un’operazione complessa, che deve considerare molti fattori, non ultimi gli skill disponibili e le preferenze del team di sviluppo.
Una volta progettata la soluzione più adatta, bisogna poi prendere tutti i diversi pezzi e assemblarli insieme. Certamente quindi serve più tempo e più lavoro rispetto a una soluzione preconfezionata, acquistabile già montata e pronta all’uso e dove basta solo premere il tasto di accensione.
Conclusione: Jamstack è da competizione
Per tirare le conclusioni e sintetizzare le differenze salienti tra una tradizionale applicazione monolitica (WordPress, Joomla, Drupal ecc.) e Jamstack, possiamo fare un paragone con il mondo delle biciclette.
La soluzione tradizionale corrisponde a una bicicletta mass market:
- La si può comprare al supermercato oppure in un negozio specializzato,
- dove ci sono molti modelli, di differenti prezzi e qualità (anche ottime),
- su cui talvolta si possono anche fare delle personalizzazioni (colore, sella, ruote ecc.).
La soluzione Jamstack è una bicicletta custom:
- viene progettata su misura da un artigiano esperto,
- offre una serie di personalizzazioni virtualmente infinita,
- viene assemblata individualmente, pezzo per pezzo,
- con estrema attenzione a tutti i dettagli.
Chi compra una bici custom spesso spende centinaia o migliaia di euro in più per avere componenti che gli consentano di ridurre di qualche kg, o di qualche centinaio di grammi, il peso complessivo.
Allo stesso modo, in una soluzione Jamstack altamente performante, spesso si possono spendere ore o giorni di lavoro per riuscire a eliminare qualche decina di Kb di peso, e conseguentemente ridurre i tempi medi di caricamento di qualche decimo di secondo.
L’architettura Jamstack non è una soluzione che va bene a tutti: è una soluzione evoluta, che serve a chi vuole investire in qualità e prestazioni ed è in grado di apprezzare come queste si traducono in un vantaggio competitivo per il suo business.
Dipende tutto da necessità e obiettivi: se l’uso che se ne fa è quello di una scampagnata ogni tanto, è assolutamente inutile spendere migliaia di euro per una bici da competizione; se invece lo scopo è correre la Parigi-Rubaix, una bicicletta high-end è indispensabile e qualche centinaio di grammi in più o in meno fa la differenza tra la vittoria e le retrovie.
Indice dell'articolo


