Che cos'è il JAMstack?

JAMstack è uno stile di architettura web che precompila il frontend in markup statico servito da un CDN, con JavaScript e API per le parti dinamiche. L’acronimo – JavaScript, API, Markup – poggia su due principi: il prerendering (il frontend viene compilato in anticipo in file statici ottimizzati) e il disaccoppiamento (frontend e backend comunicano solo tramite API). La rilettura che questo glossario aggiunge, e che le guide frontend saltano: la A è un backend. Il famoso “nessun server” del JAMstack non significa nessun backend – significa il server di qualcun altro, raggiunto tramite un’API.

Punti chiave

Il JAM in pratica

// JavaScript — the JAM in practice: static Markup, browser JS, an API for the dynamic
// The page shell was prebuilt at build time and served from a CDN.
// The dynamic 20% — auth, data, comments — is this API call at runtime:
const query = new Parse.Query('Comment');
query.equalTo('postSlug', 'what-is-jamstack');
const comments = await query.find();
render(comments); // "no server" really means: someone else's server, via an API
// The A in JAM = APIs = a backend. A BaaS is that backend, with no server to run.

// Flutter / Dart — Back4app Flutter SDK
// A prebuilt shell, made dynamic by API calls — the JAMstack pattern
final query = QueryBuilder<ParseObject>(ParseObject('Comment'))
  ..whereEqualTo('postSlug', 'what-is-jamstack');
final comments = await query.query();
render(comments.results);
// Static delivery + dynamic-via-API: the backend is a BaaS, not a server
// you provision — auth, data, and functions reached over one API.

// Swift — Back4app Swift SDK
// A prebuilt shell, made dynamic by API calls — the JAMstack pattern
let comments = try await Comment.query("postSlug" == "what-is-jamstack").find()
render(comments)
// Static delivery + dynamic-via-API: the backend is a BaaS, not a server
// you provision — auth, data, and functions reached over one API.

// Kotlin — Back4app Android SDK
// A prebuilt shell, made dynamic by API calls — the JAMstack pattern
val query = ParseQuery.getQuery<ParseObject>("Comment")
query.whereEqualTo("postSlug", "what-is-jamstack")
val comments = query.find()
render(comments)
// Static delivery + dynamic-via-API: the backend is a BaaS, not a server
// you provision — auth, data, and functions reached over one API.

La shell della pagina è stata precompilata e servita dall’edge; i commenti – la parte dinamica – arrivano a runtime tramite una chiamata API. Quella singola chiamata è l’intera architettura in miniatura: statico ovunque sia possibile, API dove è necessario, e il “server” dietro l’API è un servizio che si consuma invece di uno che si gestisce.

Stack tradizionale vs. JAMstack

Da dove arriva davvero il dinamico

La sezione che i risultati di ricerca evitano, perché rompe l’incantesimo del “serverless”. Ogni esigenza dinamica di un sito JAMstack corrisponde a una chiamata API, e dietro quell’API c’è un backend che qualcuno gestisce:

• Autenticazione → un servizio di identità o un BaaS che emette token.
• Dati → un’API di contenuti o di database che restituisce JSON.
• Form → una funzione serverless o un servizio di form.
• Ricerca, commenti, commercio → API di terze parti o del backend.

La descrizione onesta del JAMstack è quindi frontend statico + backend disaccoppiato, e il backend naturale è un BaaS: fornisce il 20 % dinamico – database, autenticazione, funzioni cloud, API generate automaticamente – senza alcun server da provisionare. Le pagine dei fornitori spingono qui un CMS headless, che gestisce solo i contenuti; un BaaS gestisce l’intero backend dinamico, ed è per questo che l’abbinamento è la risposta più completa a “come fa un sito statico a essere dinamico?”

Il dividendo di sicurezza

Il disaccoppiamento non è solo una questione di prestazioni; è anche una postura di sicurezza. Senza un server di origine che renderizza le pagine e senza un database sul percorso della richiesta, il web pubblico vede file statici, che non si prestano alla SQL injection e non eseguono alcun codice lato server da sfruttare. L’unica superficie viva è il confine dell’API – ospitata separatamente, con hardening indipendente e di solito molto più stretta di quella di un monolite. L’articolo sull’architettura disaccoppiata generalizza il beneficio; nel JAMstack si manifesta come un attaccante che trova un CDN pieno di HTML piatto dove una volta c’era il server di origine.

Il JAMstack è morto? Il verdetto onesto

La domanda più frequente merita la risposta più schietta. L’acronimo si è spento – chi lo ha creato ha ritirato il marchio “JAMstack” intorno al 2023 a favore di “composable” e “architettura web moderna”, e l’energia del marketing si è spostata altrove. L’architettura ha vinto. “Precompilare ciò che si può, recuperare il resto via API, servire da un CDN” ha smesso di essere un movimento ed è diventato un’impostazione predefinita, assorbita dalle piattaforme headless, dai meta-framework ibridi e dal rendering all’edge. Ciò che si è evoluto è la rigidità: il tutto-statico puro ha lasciato il posto alla combinazione di rotte precompilate e rotte renderizzate sul server, pagina per pagina. Il JAMstack quindi non è morto; è l’acqua in cui nuota il web moderno, e non ha più bisogno di un nome.

Casi d’uso comuni

• Marketing, documentazione e blog – contenuti uguali per tutti che cambiano a cadenza regolare: precompilare e servire dall’edge.
• Vetrine e-commerce – pagine prodotto statiche dietro un CDN, carrello e pagamento tramite API.
• Siti sensibili alla SEO – HTML precompilato che i crawler leggono all’istante, senza penalità per l’esecuzione del JS.
• Frontend statico + BaaS – il 20 % dinamico (autenticazione, dati, form) su un backend gestito.
• Lanci ad alto traffico – il CDN assorbe i picchi come un server di origine non può fare.

Conviene usare il JAMstack? Matrice decisionale

Limiti e trade-off

• I tempi di build crescono con il sito. Precompilare migliaia di pagine rende lenti i deployment; i cataloghi grandi o che cambiano in fretta spingono verso la rigenerazione ibrida.
• Dinamico significa integrazioni da cablare. Ogni funzionalità interattiva è un’integrazione API; la semplicità sta sul lato della distribuzione, non necessariamente su quello della costruzione.
• La modifica dei contenuti è meno chiavi in mano. Chi redige senza competenze tecniche ha bisogno di un CMS headless o di un livello di amministrazione; non esiste un “modifica questa pagina” integrato come in un CMS monolitico.
• Si dipende da API che non si possiedono. I servizi di terze parti sul percorso della richiesta aggiungono rischi di disponibilità e di versionamento – il disaccoppiamento è un’arma a doppio taglio.
• Non tutto dovrebbe essere statico. La personalizzazione per richiesta e i dati in tempo reale fanno a pugni con il modello precompilato; la risposta moderna è combinare, non forzare.

Il JAMstack su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. È esattamente la “A” di cui un sito JAMstack ha bisogno: la shell statica viene precompilata e servita da un CDN, e ogni chiamata dinamica fatta dal JavaScript – accesso, letture e scritture di dati, invio di form, ricerca – si risolve in un’API Back4app, senza alcun server di origine da gestire e con le ACL che fanno l’hardening dell’unica superficie viva che l’architettura espone. L’abbinamento è il completamento onesto della storia “serverless” abbozzata dalle schede di codice: distribuzione statica dall’edge, comportamento dinamico da un backend gestito, e il dividendo di sicurezza di un web pubblico che vede file piatti invece del database.