What is the JAMStack?

The Jamstack (or JAMStack) is a interesting web development paradigm first coined by Netlify’s co-founder Mathias Biilmann. The key idea of the Jamstack is that web pages that need to make API requests when they’re loaded are harder to optimize and harder to debug.

A static HTML file that doesn’t need to make any API requests has several neat advantages:

Static HTML sounds great in theory, but what about in practice when you have a website that needs to have thousands of pages? The answer is that you need a build step to compile your website, including pre-fetching any data the pages need. That’s why the tools you’ll see most commonly associated with Jamstack apps are static site generators, like Jekyll or Gatsby.

For example, suppose you’re building an eCommerce store, and you’re looking to render a list of all the products you offer. Below is an example of a list of products offered by Bay Area startup ZBiotics.

There’s many ways you can build this page. In a classic web app, a user visiting the `/all-products` endpoint would hit a server endpoint that loads products from the database and renders the HTML.

In a single page app approach, a user visiting the `/all-products` endpoint would get an HTML page, which when makes an HTTP request to a RESTful API to load a list of products from the database.

The Jamstack introduces a third paradigm: a user visiting the `/all-products` endpoint gets a static HTML page with the list of products already included. Instead of loading the products at runtime, you load the list of products at compile time.

The tradeoff is that you need to make sure you recompile your site every time your data updates. For example, if you add a new product, you need to make sure you recompile your site, otherwise you end up with an update anomaly.

Recompiling your site when data changes is tricky and subtle. Gatsby supports a notion of data sources, and Gatsby Cloud supports incremental builds based on data sources to ensure you don’t have to recompile your entire site when one small data item changes.

If you’ve been reading Mastering Mongoose, the tradeoffs of using the Jamstack may sound familiar. That’s because they’re similar to the tradeoffs for denormalizing data in MongoDB.

If you have a `BlogPost` model in Mongoose, and you choose to embed the blog post author’s name, you get the same benefits: performance, durability, and predictability. But you also risk update anomalies if you aren’t careful when you update the author’s name.

Jamstack takes the principle of denormalization to the edge (pun intended). You can think of the Jamstack as “denormalizing” your whole web app.

Because the tradeoffs are similar, the Jamstack is best suited for similar use cases as database denormalization: data that is read 1000x more than it is updated. Blog posts are a classic example. Blog posts are typically written once, and then read thousands of times.

For example, the Mastering JS website can be considered a simple Jamstack app. We have a list of blog posts in markdown, and recompile the website every time we add a new blog post.

Thanks for subscribing to the Mastering JS Weekly newsletter! As a subscriber, you can get a discounted copy of our new eBook, Mastering Mongoose. If leave a review on GoodReads after purchasing, we will give you an extra $5 back. Thanks for your continued support!