---
term: 'JAMstack'
seoTitle: 'JAMstack spiegato: JavaScript, API, Markup e il backend'
headline: 'Che cos''è il JAMstack?'
slug: jamstack
category: frontend-web
shortDefinition: '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.'
relatedTerms:
  - ssr-vs-csr-vs-ssg
  - baas-vs-custom-backend
  - cdn-content-delivery-network
  - auto-generated-database-apis
contrastsWith:
  - ssr-vs-csr-vs-ssg
aboutTerms:
  - 'JavaScript, APIs, Markup'
  - 'Pre-rendering & Decoupling'
  - 'Headless Architecture'
faq:
  - question: 'Che cos''è il JAMstack?'
    answer: 'Un''architettura web che precompila il frontend in markup statico in fase di build, lo serve da un CDN e usa JavaScript lato client che chiama API per tutto ciò che è dinamico – disaccoppiando il frontend dal backend. È un pattern, non un framework né un prodotto.'
  - question: 'Che cosa significa JAM?'
    answer: 'JavaScript, API e Markup. JavaScript gira nel browser per l''interattività; le API forniscono i dati dinamici e le operazioni lato server; il Markup è l''HTML statico precompilato servito dall''edge. I due principi fondanti sotto l''acronimo sono il prerendering e il disaccoppiamento.'
  - question: 'Qual è la differenza tra il JAMstack e uno stack tradizionale?'
    answer: 'Uno stack tradizionale, come un CMS appoggiato a un database, renderizza ogni pagina su un server, a ogni richiesta, a partire dal database. Il JAMstack serve file statici precompilati da un CDN e chiama le API solo per le parti dinamiche – nessun server di origine renderizza la pagina a ogni visita, e nessun database è esposto al web pubblico.'
  - question: 'I siti JAMstack possono essere dinamici?'
    answer: 'Sì – le funzionalità dinamiche arrivano a runtime tramite JavaScript che chiama API: funzioni serverless, un CMS headless, servizi di terze parti o un Backend as a Service. La parte "statica" è solo la shell; autenticazione, dati, ricerca e commercio passano tutti da chiamate API.'
  - question: 'Come si gestiscono autenticazione, dati e form senza un backend?'
    answer: 'Il backend c''è eccome – raggiunto tramite API invece che gestito in proprio. L''autenticazione passa da un servizio di identità o da un BaaS che emette token; i dati arrivano da un''API di contenuti o di database; i form vengono inviati a una funzione serverless o a un servizio di form. Ogni esigenza "dinamica" corrisponde a una chiamata API.'
  - question: 'Qual è la differenza tra il JAMstack e l''SSR?'
    answer: 'Il momento del rendering. L''SSR genera l''HTML sul server a ogni richiesta; il JAMstack fa il prerendering in fase di build e serve file statici. I framework moderni mescolano le due cose – rotte statiche precompilate, rotte dinamiche renderizzate sul server o rigenerate – ed è l''ibrido in cui l''idea del JAMstack si è evoluta.'
  - question: 'Il JAMstack è morto?'
    answer: 'Il termine di marketing si è spento – chi lo ha creato ha ritirato l''etichetta intorno al 2023 a favore di "composable" e "architettura web moderna". Ma l''architettura ha vinto: precompilare ciò che si può, recuperare il resto via API e servire da un CDN è semplicemente il modo in cui gran parte del web viene costruita oggi, dentro i CMS headless, i framework ibridi e le piattaforme edge.'
  - question: 'Quando conviene usare il JAMstack?'
    answer: 'Eccelle per siti di contenuti, marketing, documentazione e SEO, dove contano la velocità e una superficie d''attacco ridotta, oltre che per le vetrine e-commerce appoggiate alle API. Si adatta meno alle app fortemente in tempo reale o personalizzate a ogni richiesta, per le quali il rendering lato server o all''edge è lo strumento migliore.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'What is Jamstack? — jamstack.org'
    url: 'https://jamstack.org/what-is-jamstack/'
  - name: 'JAMstack — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/JAMstack'
  - name: 'Rendering patterns — patterns.dev'
    url: 'https://www.patterns.dev/'
  - name: 'Is Jamstack Toast? — The New Stack'
    url: 'https://thenewstack.io/is-jamstack-toast-some-developers-say-yes-netlify-says-no/'
cta:
  title: 'Il 20 % dinamico, già gestito'
  text: 'Il JAMstack precompila la shell statica; Back4app è l''API dietro il JavaScript – autenticazione, database e funzioni cloud per la parte dinamica, senza server da provisionare.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-23'
translationKey: 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 – **J**avaScript, **A**PI, **M**arkup – 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

| Domanda | Risposta |
| --- | --- |
| JAM | JavaScript (browser) · API (dinamico) · Markup (statico precompilato) |
| I due principi | Prerendering + disaccoppiamento |
| Distribuzione | File statici da un [CDN](/glossary/it/cdn/) – nessun rendering all'origine per richiesta |
| La "A" | API = un backend ([BaaS](/glossary/it/baas-vs-backend-personalizzato/), funzioni, servizi headless) |
| "È morto?" | Il termine è andato in pensione; l'architettura ha vinto ed è diventata ibrida |

## Il JAM in pratica

**JavaScript:**

```javascript
// 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
// 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:**

```swift
// 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:**

```kotlin
// 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

```mermaid
flowchart LR
  accTitle: Stack tradizionale renderizzato sul server contro JAMstack
  accDescr: In uno stack tradizionale, ogni richiesta del visitatore raggiunge un server web di origine che interroga un database e renderizza l'HTML a ogni richiesta. Nel JAMstack, il frontend viene precompilato in markup statico in fase di build e servito da un CDN, e il JavaScript del browser chiama API disaccoppiate per i dati dinamici, così nessun server di origine né database è esposto sul percorso della richiesta.
  subgraph T["Tradizionale (per richiesta)"]
    U1["Visitatore"] --> WS["Server di origine<br/>renderizza l'HTML"] --> DB1[("Database")]
  end
  subgraph J["JAMstack (precompilato + API)"]
    U2["Visitatore"] --> CDN["CDN<br/>markup statico precompilato"]
    U2 -->|"il JS chiama le API<br/>per i dati dinamici"| API[("API disaccoppiate<br/>BaaS · funzioni · CMS")]
  end
```

| | Tradizionale (rendering lato server) | JAMstack |
| --- | --- | --- |
| Produzione dell'HTML | A ogni richiesta, sull'origine | In [fase di build](/glossary/it/ssr-vs-csr-vs-ssg/), precompilato |
| Servito da | Un server web di origine | L'edge di un [CDN](/glossary/it/cdn/) |
| Dati dinamici | Renderizzati inline dal database | JavaScript che chiama le API |
| Accoppiamento | Frontend e backend fusi | [Disaccoppiati](/glossary/it/architettura-disaccoppiata/) tramite API |
| Superficie d'attacco | Origine + database esposti | File statici + un'API con hardening |

## 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](/glossary/it/baas-vs-backend-personalizzato/) che emette [token](/glossary/it/json-web-token-jwt/).
- **Dati** → un'[API](/glossary/it/api-generate-automaticamente/) di contenuti o di database che restituisce JSON.
- **Form** → una [funzione serverless](/glossary/it/cloud-code-funzioni-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](/glossary/it/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](/glossary/it/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](/glossary/it/ssr-vs-csr-vs-ssg/), 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](/glossary/it/baas-vs-backend-personalizzato/)** – 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

| Situazione | Tendenza |
| --- | --- |
| Contenuti, documentazione, marketing, SEO al primo posto | JAMstack – il suo terreno naturale |
| Frontend statico che ha bisogno di dati dinamici | JAMstack + un [BaaS](/glossary/it/baas-vs-backend-personalizzato/) per l'API |
| Pagine fortemente personalizzate, per richiesta | [Rendering lato server](/glossary/it/ssr-vs-csr-vs-ssg/) o edge |
| App in tempo reale, molto interattiva | Rendering lato client + [dati live](/glossary/it/live-queries-tempo-reale/) |
| Numero enorme di pagine, modifiche frequenti | Ibrido – precompilare una parte, renderizzare il resto |
| Superficie d'attacco ridotta come priorità | JAMstack – il dividendo di sicurezza |

## 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](/glossary/it/autenticazione-vs-autorizzazione/), letture e scritture di dati, invio di form, ricerca – si risolve in un'[API](/glossary/it/api-generate-automaticamente/) Back4app, senza alcun server di origine da gestire e con le [ACL](/glossary/it/liste-di-controllo-degli-accessi-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.