I siti statici sono ormai da anni la novità dello sviluppo web, tant’è che è stato coniato un nuovo termine: JAMstack. Viene (tanto per cambiare :) ) dagli States ed ha l’obiettivo di spingere sempre di più questo rivoluzionario modo di interpretare le architetture per i siti web.
Ogni giorno su podcast, articoli e blog vedo e sento sempre più persone che convertono i loro siti web in siti web statici di nuova generazione. Beh, anche io sono uno di quelli e questo blog rientra a pieno titolo nella definizione di JAMStack.
Quindi cerchiamo di capire il perché di tale successo.
Che cosa si intende per JAMStack?
Iniziamo col citare il CEO e co-founder di Neltify Mathias Biilmann che definisce il termine in questo modo:
“Una moderna architettura di sviluppo web basata su JavaScript lato client, API e markup pre-compilato” — Mathias Biilmann
Il concetto sta tutto in 3 passaggi fondamentali che costituiscono l’acronimo JAM: Javascript, API e Markup
- Javascript
Questa è la vera parte dinamica dell’architettura. Qui non ci sono limiti alla fantasia o restrizioni su quale framework o libreria usare, basta che si rispetti il requisito primario: deve essere appunto in Javascript.
Per questo sito, ad esempio, ho preferito usare Gatsby, che combina la parte migliore di React, GraphQL e React-router per darti un generatore di siti statici che è molto intuitivo per gli sviluppatori. E’ infatti il framework più veloce e immediato come tempi di apprendimento tanto da essere più volte definito (anche erroneamente) come il Wordpress del JAMStack, ma ce ne sono molti altri validissimi, cito qui i nomi più famosi: Hugo, Jekyll, Eleventy, NextJS, ecc.
- API
Le operazioni lato server vengono astratte in API riutilizzabili e accessibili tramite HTTPS con JavaScript. Sempre facendo un esempio concreto, io sia per lavoro che per progetti personali, ho avuto l’opportunità di provare Contentful, attualmente, a mio avviso, uno dei migliori headless CMS in circolazione. Ma ce ne sono molti altri con le stesse caratteristiche, rimando alla pagina di JAMStack.
Non solo CMS, ci sono delle ottime piattaforme ecommerce completamente headless, un esempio su tutti CommerceLayer
- Markup
E qui viene il bello… I siti web vengono serviti come file HTML statici. Questi possono essere generati da source file, come Markdown, oppure utilizzando generatori di siti statici come quelli citati al punto prima.
I file HTML generati saranno serviti da una Content Delivery Network (CDN), un esempio su tutti, utilizzata per servire questo sito, è Netlify… ma di questo ne parlerò più avanti nell’articolo.
Quindi per essere chiari, ciò che ha reso popolare questo tipo di architettura è proprio la capacità di sfruttare la parte dinamica tramite framework in Javascript per poi generare una build statica ed ottimizzata del codice HTML.
Questo processo di pre-rendering si traduce in siti che possono essere serviti direttamente da una CDN (come Netlify), riducendo il costo, la complessità e il rischio dei server dinamici.
Moderna Architettura JAMStack
Perché statico è meglio
Perché semplicemente non hai motivo di avere un enorme ed ingombrante CMS o un’applicazione monolite con un database e un server da mantenere quando potresti avere un sito con caratteristiche comunque dinamiche (la parte javascript che menzionavo prima), veloce e sicuro.
Vediamo nel dettaglio 5 motivi per cui statico è meglio:
1 - Velocità
Non è una novità. Nel campo dello sviluppo web, a qualsiasi livello ci si concentra continuamente sulle performance. Croce e delizia dei siti di oggi. I siti spesso sono sì belli, moderni e tecnologicamente avanzati, ma spesso le performance lasciano a desiderare.
Nello specifico, ci si concentra molto sul “Time to First Byte”, che misura il tempo che va dalla richiesta iniziale al primo byte ricevuto dal browser.
Ecco, nel caso dei siti statici, poiché sono pre-compilati, il tempo necessario per generare dinamicamente il contenuto viene completamente eliminato. Ciò significa: nessuna query al database, nessun templating html, ecc.
Prova, ne rimarrai stupito. La prima volta che provai a buttare la mia prima build sulla CDN pensavo di stare ancora su localhost!
2 - Sicurezza
Secondo una stima, il 70% di tutte le installazioni di WordPress è vulnerabile a noti exploit di sicurezza. Nel 2014, milioni di siti Drupal erano vulnerabili a causa di un bug nel codice. Drupal ha comunicato agli utenti che se non avessero aggiornato il codice all’ultima versione entro 7 ore dall'annuncio, probabilmente avrebbero potuto ricevere un attacco.
Immagina: solo 7 ore! E’ una finestra temporale piccolissima. Pensa ad un’agenzia di provincia che ha fatto decine di installazioni e deve aggiornare il software ad ogni singole cliente.
Con un sito statico, non devi preoccuparti se del codice dannoso viene iniettato nel tuo sito, perché in produzione hai solo “roba statica”, quindi HTML, CSS, Javascript e asset multimediali.
Quando un utente richiede una pagina, il server invia semplicemente il file per quella determinata pagina. Gli attacchi hacking standard come lo scripting o gli exploit di sicurezza del database, come il SQL injection per portare un caso comune, semplicemente non funzionano.
3 - Semplicità di gestione dell’hosting
Come dicevamo, tutto ciò che il tuo provider host deve fare è fornire risorse statiche. Stop. L'host non deve supportare un linguaggio back-end o un framework specifico. Non si preoccupa minimamente delle specifiche della tua applicazione. L'hosting ha solo bisogno di prendere i file che tu gli passi e servirli velocemente!
Questo vuol dire semplicità di gestione, ma anche risparmio in termini economici. I file HTML e CSS pesano poco di conseguenza anche il tuo spazio sul web avrà delle basse spese di gestione.
Questo ti permetterà di investire i tuoi risparmi in quello che è veramente importante per te, come ad esempio nuove funzionalità per il tuo sito web.
4 - Ottima esperienza per lo sviluppatore
Il flusso di lavoro è probabilmente sottovalutato quando si considerano nuove tecnologie o nuovi framework. Con i siti statici, l'esperienza è uno dei vantaggi più importanti. Dopo un po' di configurazione iniziale, il flusso di lavoro è fluido.
Non devi fare altro che concentrarti sul front-end. E quando devi andare in produzione i passaggi da seguire sono chiari e semplici:
- Connetti la tua app ad un repository git (Github, Bitbucket, ecc.)
- Configuri la tua build (branch name e comando per lanciare la build, ad esempio “gatsby build”)
- Monitori lo stato del deploy da back-office
5 - Disaccoppiamento del front-end dal backend
Beh, è proprio il caso di dire “last but not least”.__ Infatti uno dei veri vantaggi è che non hai più il monolite__ (come nel caso di Wordpress, Drupal o Joomla!). I progetti Jamstack separano nettamente le pagine front-end e l'interfaccia utente dal back-end e dai database.
Come dicevo al punto precedente, come front-end developer, tutto quello che devi fare è concentrarti proprio sullo sviluppo JS, HTML e CSS. Lo sviluppatore back-end penserà a lavorare al set di API lato server. Oppure, addirittura tutto diventa ancora più semplice se si utilizza un headless CMS, dove il set di API viene generato automaticamente non appena si configura il data-model a livello di back-office.
La CDN: l’esperienza con Netlify
La cosa che mi ha stupito di più è la semplicità con cui si è in grado di andare live.
Da quando inizi a leggere la documentazione fino a quando il tuo sito è deployato in un custom domain fornito da Netlify stesso, passa massimo 2 ore. Tutto questo a costo zero! Netlify aggiunge inoltre sicurezza al tuo sito con l’opzione SSL gratuita… e l'installazione si fa in un click, così da avere l’HTTPS immediatamente disponibile.
Il piano gratuito ha tutto quello che serve per poter avere un sito web live in tempi rapidi con funzionalità eccezionali. Una di queste? Il Continuous Deploy o CD per gli amici ;)
Ogni volta che fai il deploy del tuo progetto su un repository Git, Netlify attiva automaticamente il CD per te. Ogni volta che effettui una nuova commit e fai una push sul tuo repository, Netlify crea una nuova build di file statici e aggiorna automaticamente il tuo progetto alla versione più recente.
Tutto ciò si ottiene senza dover scrivere file di configurazione o un lungo elenco di regole, ma semplicemente lavorando 5 minuti sulle configurazione nel back-office di Netlify.
Inoltre si può facilmente scegliere quale branch del tuo progetto Git sarà sottoposto a CD. Ovviamente Netlify attiverà il deploy solo per quel branch.
Per farti un esempio concreto, puoi scegliere di fare il deploy ad ogni commit sul branch “master”, e di tenerti un branch “development” per salvarti i progressi dei tuoi sviluppi. Quando il lavoro è finito, tutto quello che devi fare è semplicemente una pull request verso master. Al merge, partirà il deploy automatico.
Tutto rose e fiori?
Beh, no… stiamo parlando sempre di siti statici. Ci sarà un motivo se diversi anni fa quando si parlava di “statico” ai professionisti del web venivano i bordoni.
Sicuramente il JAMStack ha dato nuovo impulso a questo tipo di architettura e i tempi sono più maturi di un tempo per avere degli static site generator performanti e delle CDN intelligenti.
Ci sono comunque dei casi da considerare in cui forse potresti mettere in discussione - anche parzialmente - questa scelta.
Bisogna considerare infatti che ogni volta che viene prodotto un nuovo contenuto (anche piccolo) si deve ricompilare tutto il progetto. Immagina quando hai un sito con tantissimi contenuti. Potresti riconsiderare un'architettura leggermente diversa per non allungare i tempi di build, specialmente se hai una struttura con molti utenti di back-office che pubblicano nello stesso momento.
Sicuramente Gatsby è il master dei siti 100% statici, ma per applicazioni un po’ più complesse, entrano in gioco framework un po’ più evoluti come Next.js o Nuxt.js entrambi molto validi.
Next.js, ad esempio, è uno strumento utilizzato per creare siti web renderizzati lato server che generano l'HTML dinamicamente ogni volta che arriva una nuova richiesta (SSR, server side rendering).
L’impiego ideale per questo framework è per la creazione di siti web di e-commerce. Il suo punto di forza infatti è quello di poter scegliere di mantenere statiche alcune parti del sito web, come la pagina dei contatti o le informazioni di spedizione, e utilizzare il server per visualizzare le pagine contenenti contenuto dinamico, come le pagine di prodotto.
Quindi, in sintesi cosa scegliere?
Se hai molti contenuti o se ti aspetti che i tuoi contenuti crescano molto nel tempo, le pagine web generate staticamente non sono la soluzione migliore per te, in quel caso invece di considerare l’uso di Gatsby inizierei a documentarmi su Next.js e Nuxt.js.
Qui un articolo molto interessante per comparare i 3 framework in questione.
Per concludere...
Spero che in questo articolo sia stato reso evidente il valore che il JAMStack ha non solo sull'esperienza di sviluppo, ma anche i vantaggi reali sulla user experience in termini di sicurezza e performance.
Non resta che provare.
