Serverless e Jamstack, il futuro dello sviluppo web

Il Web è in perenne evoluzione, e negli ultimi anni è stato teatro di cambiamenti notevoli.
L'ultimo anno di emergenza sanitaria ha sottolineato la necessità di avere siti veloci, affidabili e scalabili, mettendo in discussione i paradigmi classici dello sviluppo web su stack monolitici.

Recentemente si è parlato molto di Jamstack: è la crasi di JAM (acronimo di Javascript - API - Markup) e Stack, ovvero l'ambiente di sviluppo.
La definizione ufficiale da Jamstack.org è questa:

Jamstack is an architecture designed to make the web faster, more secure, and easier to scale. It builds on many of the tools and workflows which developers love, and which bring maximum productivity. The core principles of pre-rendering, and decoupling, enable sites and applications to be delivered with greater confidence and resilience than ever before.

Jamstack prevede il "decoupling" di content e frontend: mentre in uno stack tradizionale abbiamo sulla stessa macchina il CMS (ad esempio Wordpress) in cui inserire i contenuti e la parte di frontend visibile all'utente, con una soluzione Jamstack il CMS può essere ovunque - o non esserci affatto - mentre il frontend verrà generato in maniera statica, per poi essere pubblicato su una delle tante soluzioni "serverless" e servito tramite CDN. 

A cosa serve e come funziona

Le basi dell'architettura Jamstack vengono gettate intorno al 2015, quando gli sviluppatori iniziano a sentire l'esigenza di dare alle applicazioni web una struttura più simile a quelle mobile: pre-renderizzate, distribuite, in grado di interfacciarsi efficacemente con API e microservizi.
Si può pensare a Jamstack come un "collage" di diverse tecnologie e servizi, che vengono combinati per ottenere un sito statico caratterizzato da velocità, stabilità, sicurezza e scalabilità.
Andiamo ad esaminare brevemente le entità coinvolte.

Framework / Static Site Generator (SSG): è il "cuore" del frontend. Tra le soluzioni più famose, alcune sono basate su Node.js e React (NextJS e Gatsby), altre sulla lettura di file statici (Hugo). Il generatore statico interroga il CMS - solitamente tramite API / GraphQL - e genera una versione statica del sito, pronta per essere sincronizzata con un repository ed essere servita tramite CDN.

Content Management System (CMS): è dove vengono inseriti i contenuti. Può essere un banale Wordpress utilizzato in modalità "headless" (ovvero senza frontend), un CMS proprietario, oppure un servizio di tipo PaaS (Platform as a Service) come Contentful, Prismic, Sanity.io, che a fronte di un canone mensile forniscono una piattaforma di gestione dei contenuti, un quantitativo di spazio per il caricamento degli asset (immagini e video) e un plafond mensile di chiamate API.

Microservizi: come si può facilmente immaginare, un sito statico non permette di offrire aree interattive: ricerca, form contatti, registrazione/login, e-commerce.
Per ovviare a questa carenza, si cerca di integrare il sito statico con microservizi che offrano tali funzionalità, implementandole tramite Javascript e API.
I microservizi possono essere sviluppati in proprio, oppure ci si può appoggiare a piattaforme di terze parti in base alle necessità: ad esempio, Algolia per la ricerca, Typeform per le form di contatto, Auth0 per registrazione e login, Snipcart per l'e-commerce.

Deploy Platform: sono l'equivalente di quello che è l'hosting negli stack tradizionali. Dialogano con il nostro repository e con il nostro CMS headless, rilevando le modifiche avvenute e aggiornando la versione statica del sito sulla CDN.
Un esempio è Netlify, fondata dall'imprenditore danese Mathias Biilmann e divenuta ormai tra le aziende di cloud computing più famose al mondo.
I maggiori player del settore (Amazon, Cloudflare, Digital Ocean, Microsoft) hanno lanciato negli ultimi tempi le proprie soluzioni personalizzate, che si differenziano per bundle forniti ma anche per l'offerta di funzioni dinamiche utilizzabili in aggiunta al sito statico.
In altri casi, gli stessi sviluppatori di framework famosi hanno dato vita a piattaforme che consentono il deploy rapido dei progetti creati con il loro software, come ad esempio Vercel per NextJS o Gatsby Cloud per Gatsby.

Il case study più famoso è probabilmente Smashing Magazine, storico blog dedicato al mondo del Web Design.
Nel 2017 Smashing Magazine ha iniziato - con ben 56 illustrazioni di gatti sul loro nuovo sito - il suo percorso di restyling e di transizione verso il mondo Jamstack, dopo oltre un decennio di Wordpress per la parte blog, e di soluzioni sviluppate ad hoc per le aree Books, Jobs, Podcast, Newsletter.
I dettagli della migrazione sono trattati più diffusamente nell'e-book "Modern Web Development on the Jamstack".

I vantaggi

Negli ultimi anni si è dedicata sempre maggiore attenzione alle prestazioni dei siti Web, anche in seguito alle modifiche degli algoritmi dei motori di ricerca, che privilegiano il posizionamento di siti con ottime prestazioni e con FCP/LCP/FID molto bassi.
In genere si affrontano 3 temi nell'ottimizzazione prestazionale di un sito: una progettazione razionale ed essenziale, la creazione di aree statiche o sotto caching, e una buona connettività.
Per il primo tema, purtroppo, non c'è tecnologia che tenga. Per la staticità si ricorre generalmente a plugin di caching - lato CMS o lato server - che però hanno spesso diversi punti deboli. Per la connettività, infine, si cerca di potenziare la struttura server, o di porre rimedio con una CDN che serve una copia "statica" del sito.

Jamstack offre tutto questo (ed altro) in modalità nativa.

• Con i generatori di siti statici si creano delle copie pre-renderizzate e totalmente statiche dei siti, che vengono servite tramite CDN alla massima velocità possibile e senza limitazioni geografiche.

• Sono quasi inesistenti downtime, attacchi e crash del sito; un eventuale picco di traffico può essere gestito semplicemente ricontrattualizzando il rapporto con il fornitore della CDN.

• Il CMS non è pubblicamente esposto sulla stessa macchina del sito, ed è quindi sensibilmente meno soggetto ad attacchi e potenziali data breach.

• Il frontend non è strettamente legato al CMS usato: un eventuale cambio di CMS nel corso del tempo può essere gestito con modifiche minime al codice; inoltre, essendo il sito servito staticamente tramite CDN, si potrà sviluppare la nuova versione senza causare disservizi agli utenti e a chi si occupa del content.

• Lo stesso CMS headless può essere utilizzato sia per un sito web che per altre applicazioni su differenti device.

• Si evita lo sviluppo di microservizi dedicati all'e-commerce o ai pagamenti, avvalendosi del supporto di partner di livello.

• Non bisogna occuparsi di tutte le questioni sistemistiche, di mantenimento e di messa in sicurezza dei server.

Gli svantaggi

Ovviamente, l'altro lato della medaglia presenta diversi svantaggi.
Per prima cosa, Jamstack non è per tutti.
Non lo è per la curva di apprendimento abbastanza ripida, ma anche perché bisogna valutare molto bene costi, controindicazioni e tempi di sviluppo per il singolo progetto.

Per quanto riguarda i costi, bisogna valutare con attenzione: consumi di banda, costi extra richiesti per funzioni serverless, e i costi di tutto l'ecosistema di microservizi indispensabili per realizzare il progetto.

Altri svantaggi possono essere:

• È un settore relativamente nuovo, in molti casi può essere difficoltoso trovare supporto, documentazione, community dedicate.

• Per lo stesso motivo, può essere difficile trovare sviluppatori esperti in questo ambito.

• CMS Headless da mantenere: nel caso si opti per un'installazione di Wordpress, sarà necessaria la messa in opera di un server, la gestione della sicurezza e il mantenimento (con i relativi costi).

• Operazioni di import/export molto lunghe e laboriose per siti già esistenti o in caso di cambio di CMS.

• Difficoltà per chi gestisce il content nell'adattarsi al nuovo CMS o alla pubblicazione tramite markdown file; funzioni banali come la preview del contenuto pubblicato o la visibilità immediata dopo la pubblicazione sul sito non sono scontate e vanno previste in fase di realizzazione.

• Tempistiche di rebuild: l'aggiunta di nuovi contenuti richiede il "rebuild" del sito statico; a seconda della complessità del sito, questa operazione può richiedere da alcuni minuti a diverse ore. Alcuni framework hanno introdotto nel tempo la possibilità di effettuare rebuild incrementali.

• Tempistiche di sviluppo: rispetto ai CMS classici, molte funzioni banali come il routing, la creazione di archivi, di sitemap, di feed, non sono built-in nella maggior parte dei framework Jamstack, ma devono essere implementate ex-novo dallo sviluppatore.

• Scarsa flessibilità di personalizzazione, in particolare per le funzionalità che fanno affidamento su microservizi di terze parti.

• Possibilità che piattaforme scelte per l'implementazione dei microservizi possano cessare la loro attività o rivedere le condizioni contrattuali.

• Mancanza di uno stack "tradizionale" in cui poter installare applicativi di supporto, settare dei cron job, ecc.

• Possibili problematiche legali nel doversi avvalere di servizi esterni al territorio nazionale/UE per trattare e processare i dati degli utenti.

Conclusioni

Si tratta di un ambiente ancora acerbo e assolutamente in divenire, ma la strada segnata è quella giusta, ed è facile immaginare che prenderà sempre più piede nei prossimi anni.
Sul fronte framework e CMS headless, oggi abbastanza numerosi, assisteremo probabilmente ad una "selezione naturale" in favore dei player più forti e in grado di conquistare la fiducia degli sviluppatori.
La stessa cosa accadrà nell'ambito delle Deploy Platform, con la prevalenza dei player che offrono bundle più convenienti, maggiore velocità e affidabilità, funzionalità ad hoc per gli sviluppatori e integrazione con i servizi esistenti.
Per gli sviluppatori sarà fondamentale aggiornarsi e non farsi cogliere impreparati dall'avanzare di questa tecnologia.
Gli utenti, infine, avranno a disposizione dei siti web molto più veloci e affidabili, e fruibili con meno difficoltà anche su dispositivi mobile o in situazioni di difficile connettività.
Il rischio - o l'opportunità, a seconda dei punti di vista - è che anche in termini di esperienza d'uso, come già accaduto per il design, i siti del futuro diventino molto più "standard" e con lievi differenze tra loro; la partita si sposterà quindi su altri fronti, tornando a dare maggiore enfasi al contenuto o ai servizi offerti, nel tentativo di differenziarsi dai competitor.