Jamstack - Are static sites and APIs reinventing the web?

Posted Jan 28, 2021

Jamstack is one of the hottest topics in web development right now. Is this new architecture going to re-invent the web?

What is Jamstack? #

Jamstack is an architecture for web applications that promises to be faster, cheaper, and more secure than the traditional model i.e. the "client/server" model where applications are served dynamically from a web server.

The key idea of Jamstack is that there is no backend server for the app, at least not in the form that we're used to.

Jamstack apps consist of static HTML pages made dynamic with JavaScript and enhanced with third-party services accessed via API.

This is where the name Jamstack comes from - (J)avaScript, (A)PIs, and hypertext (M)arkup.

To understand how Jamstack works and how it will (supposedly) outperform the client/server architecture, we're going to now dive into the underlying concepts.

Traditional client/server architecture #

Firstly, let's clarify the client/server model albeit in an oversimplified way.

Here, you have a web server connected to the public internet. When a browser somewhere requests a web page the server is hosting, the server will process the request with backend software (like WordPress, Rails, Deno, Node.js, or one of the many other options).

After consulting the database and running various other logic, the backend will generate a web page and send it back to the requesting browser.

Client <--> Internet <--> Server

Jamstack architecture #

Jamstack sites do not have a backend server. Instead, Jamstack sites are simply static files that are not processed or customized. These files are served by a special type of file-hosting called a content delivery network.

A "CDN", as they're more commonly known, is actually a network of file servers around that world, all holding a copy of your site's files.

When a browser requests your site, this request gets routed to the physically closest file serving, ensuring the fastest possible response.

Client <--> Internet <--> CDN

The role of APIs #

Now, wait a minute. If Jamstack sites are static, does that mean they're just boring HTML pages? Wouldn't we want to personalize them with user data?

This is where the "J" and "A" in Jamstack comes in - JavaScript and APIs.

Once your static site has been loaded by a browser, you can use JavaScript to generate HTTP requests to third-party services including databases, search, identity management, payment processing, and more.

Let's compare how a client/server site and a Jamstack site would approach storing and retrieving data.

In the client/server site, the database would be hosted on the server. For example, we might have a Postgres database.

During the request/response loop, any data need by the site might be merged into the page sent back in the response.

Client <--> Internet <--> Server <--> Database

In the Jamstack site, you might instead have a cloud-hosted Postgres database by using a service like Hasura. This database would be interfaced with a public API. During the app lifecycle, it would request the data using AJAX and merge it into the live HTML page.

// 1.
Client <--> Internet <--> CDN

// 2.
Client <--> Internet <--> Database

As you can see, this makes the request/response loop shorter.

Benefits of Jamstack #

So why go to this hassle of turning a web app architecture upside down like this?

As mentioned, this architecture promises that it will be faster, cheaper, and more secure. Most of these benefits are a direct result of eliminating the web server and instead using a CDN. Let's see why that is.

Faster #

Since a CDN does not process requests and instead just serves files, the request/response loop is much shorter. And since CDNs can serve on the network edge, closer to the user, the latency of the response is minimized.

Cheaper #

If you use a web server, it will, of course, need to be running 24/7, listening for requests. Since cloud computing is charged by the minute, you'll be paying for your server even in times when it's idle.

A CDN service will instead be charged by the volume of data served, and therefore idle time is irrelevant.

More secure #

Finally, unlike a web server, a CDN does not process requests and therefore has very limited attack vectors for hackers.

A Jamstack site will still connect to services like cloud databases, but since these are managed by specialist third parties, security holes are usually minimized.

Static-site generators #

So how do we go about building a Jamstack site? For example, say we wanted to build a news site with paywalled content.

The first thing we do to build a Jamstack site is to choose a static-site generator. This is a publishing tool that will create static files based on source files.

For example, on our news site, we might have articles written in markdown format, while the blog layout is created with JavaScript and SASS for CSS.

The static-site generator will process these dynamic source files and spit out static files ready to be deployed to a CDN.

Choosing a static-site generator #

In recent years there have been many static-site generator frameworks created including Gatsby, Next, Hugo, Eleventy, and Nuxt. Of course, each is different in their features and capabilities.

Let's say we decided to use Nuxt for our news site. This one allows us to build a single-page application using Vue.js that can be statically rendered.

So, we'd first create our basic site content the same way we would with any kind of frontend application.

Choosing APIs #

Now given this is a static site, how would we create a feature allowing users to subscribe and pay?

For this, we can use Snipcart, an API-based eCommerce service.

We'll also need to create user accounts so that paying users can access the paywalled content. Again, this is not achievable without a database and backend logic.

So, we'll use Auth0, which is again an API-based service that provides identity management.

The next complication we face is - how do we allow our API services to talk to each other securely?

For this, we could use a serverless function. This is a snippet of code that can be run on-demand in the cloud.

We could write a serverless Node.js script that will be triggered by a webhook coming from Snipcart after a subscription is purchased.

This script would make a secure API connection to Auth0 and update the user's access privileges.

Deploying Jamstack #

Once we're done, we can run a build in Nuxt to generate our static site. Now it's ready to be deployed to a CDN.

Rather than deploying directly to a CDN, using a static-site host is probably a better option.

These services, including Netlify, AWS, Vercel, and Cloudflare, provide git-based workflows for CDN deployment that are far simpler than doing it manually.

So let's say we choose Netlify as our static host. Once we've set up our app, we can deploy it with nothing more than a git push.

$ git push origin master

Netlify will detect this push and use the codebase as a basis for a new deployment.

It will trigger the static site build in its own servers, and deploy the static files to a CDN and deploy the serverless function to the cloud.

Git server --> Netlify --> CDN

Criticisms of Jamstack #

Some developers have criticized Jamstack. Most notably, WordPress founder Matt Mullenweg called Jamstack a "regression for the vast majority of the people adopting it".

A more specific criticism is that Jamstack is fragile. To be able to recreate the same functionality of a monolith site like WordPress, for example, you'd need quite a variety of third party services. This will also make the costs far larger than a regular site, despite the cheaper hosting.

That said, it's probably too early to make a final judgement as Jamstack is still relatively young and is evolving rapidly.

One thing we can probably say for sure, though, is that the advantages of Jamstack are best suited for public-facing websites where speed and scale are a factor.

For an admin site or some other kind of internal tool, it'd make more sense to stick with a monolith site like Laravel or Rails.

One last question we'll address is - why has Jamstack only become popular now?

While the concept of the architecture may not be new, there are several factors that needed to conspire for Jamstack to work.

Firstly, Jamstack wasn't as feasible without recent improvement in web browsers and web APIs. For example, APIs for managing browser history are necessary to allow for the single-page app architecture that's popular in Jamstack sites.

Secondly, deploying Jamstack wasn't as attractive without the recent improvements in cloud computing. It's now very cheap to build and test in the cloud, and to access features like serverless functions.

Finally, Jamstack leans heavily on the API services like Stripe, Auth0, and Shopify, collectively known as the API economy.

It's only recently reached a critical mass where Jamstack sites can get feature parity with monoliths like WordPress and Laravel.

Wrap up #

Jamstack promises a faster, cheaper, more secure, and more feature-rich web.

Given the advantages of Jamstack, many people in technology are expecting the popularity of Jamstack to increase.

Indeed, a lot of investment money is currently being contributed to static-site generator software, static-site hosting services, and the API economy.

While it's impossible to know if Jamstack will one day be the dominant architecture of the web, it does appear to be growing rapidly.

For this reason, we highly recommend you learn the skills of Jamstack.

You might also like...

Did you enjoy this review? To help us bring you more just like it, consider sponsoring Dev Reviews on Patreon!

Become a Patron