Jamstack: the build, the CDN and the webhook

Jamstack is an approach where pages are built ahead and served from a CDN, while dynamic parts come from APIs and services. A webhook picks up CMS edits.

What Jamstack is

The word was coined in the 2010s: JavaScript, APIs and Markup. It was made popular by Mathias Biilmann, a founder of Netlify, in a talk in 2016. Today the Jamstack.org site describes the approach like this: the display of a page is separated from the data and the logic, and the logic you need and third party services are plugged in through APIs. The word “Jamstack” has become less fashionable in marketing, but the idea has stayed. It’s also called the “composable” web.

In practice this means three things, and you already know each of them:

1. Pages are built ahead of time (lesson 5): ready HTML files sit on the server.
2. They are served through a CDN (a network of servers around the world: the nearest copy hands out the page quickly; details in part 9).
3. Dynamic parts come from outside: the content from the API of a headless CMS (lesson 6), and forms, search and payments from services or short functions.

The path of an edit to the visitor

The most important mechanism here is how an edit in the CMS reaches the live site. That’s why the webhook, the build and the rollback are worth seeing live. Press “Publish”, step through, and break any stage.

A model with invented seconds. Check a stage that will “break”, then walk through the path of an edit step by step.

1. Publish in the CMS break it
   The editor pressed “Publish”: the entry is saved.
2. Webhook break it
   The CMS sent the builder a message: “the content has changed”.
3. Build break it
   The generator takes the content from the API and rebuilds every page.
4. Deploy break it
   The finished folder is uploaded to the host and switched on in one go.
5. Delivery (CDN) break it
   Copies of the pages around the world are refreshed and the old cache is cleared.

Publish Start over Roll back to the previous version

The visitor sees now: v12: the previous version.

Pages on the site: 200

The build will take about 25 s, and the whole path from “Publish” to visitors about 42 s. For a small site this is almost instant.

Text alternative: an edit passes through five stages: publish, webhook, build, deploy and refreshing the copies on the CDN. If one of them breaks, the visitor keeps seeing the previous version, because the new one is switched on whole and only after a successful build. A rollback is a switch to the previous built version. Build time grows with the number of pages.

What to notice.

• A webhook is a “phone call”: the CMS itself tells the builder “the content has changed”. Without it, someone would have to start the build by hand.
• The deploy is atomic: a new version goes live as a whole, and only after a successful build. That’s why a failed build doesn’t break the site: the visitor keeps seeing the previous version. Even on a live site there’s no “half updated” state.
• A rollback is a switch to the previous built version. Hosts keep them, and going back takes seconds. After that you fix the entry in peace and publish again.
• Time grows with the size of the site. For two hundred pages a build takes under a minute, and for ten thousand it’s noticeable. That’s the limit of building ahead of time: every edit rebuilds everything. The answers are fast generators, rebuilding only the pages that changed, and pages built on request and then cached (a hybrid that modern frameworks can do).

Check yourself: what does a visitor see if the build failed?

The previous version. A new version goes live only after a successful build, and as a whole, so the site stays on the last working one.

What such a site lacks

A static site has no server code: it can’t take a form by itself, search a database or accept a payment. There are three ways around that, and you have met them already:

• An outside service. A form service takes the form (and forwards it to email, a spreadsheet or a messenger), a payment service takes the payment, and search is built as an index that is generated along with the site, or as a service.
• A short function. A “serverless” function (see part 9) runs on request, takes the data and does something with it. It’s server code all the same, only small, and without a server you have to manage.
• Your own API. If there’s a lot of logic (user accounts, orders), you need a real server, and the site stops being purely static. That’s fine: Jamstack isn’t a dogma, it’s a way to move to a server only what needs it.

And here the topic of lesson 7 in part 7 comes back. Any outside service that takes an inquiry receives visitors’ personal data. You’re still the one responsible. You need consent and a privacy notice next to the form, and an answer to “where does the service store the inquiries, and in which country?”. Under the GDPR, sending data outside the EU needs a legal basis, and the US state privacy laws (California’s, for instance) expect a contract with a service provider and honest notices. In practice you pick a provider that signs a data processing agreement and lets you choose where the data is stored. Make that choice on the scheme, not by accident. This is general information, not legal advice: for your own case, ask a privacy attorney or your data protection authority.

Practice

You’re in 2022: the site is built from the CMS by a webhook and sits on a CDN. Describe the deployment scheme of your project in four steps (source, build, deploy, delivery), name the service or function that handles the visitor’s main action, say where the personal data will land, and how you would roll back a bad publish.

What was wrong with the older way

The first “edit, then rebuild” setups needed a developer to start the build by hand and copy the files over FTP: one careless move and the site was half updated. A host’s atomic deploys, a one-click rollback and webhooks removed that manual mistake and many others.