A faster and more secure website with JAMstack

JAMstack is a collection of technologies (JavaScript, APIs and Markup) used to build dynamic websites. Here we explain more about what it is and how it can help your website become both faster, more secure and more scalable.

What is JAMstack?

JAMstack is the name of a specific architecture for building websites. JAM stands for JavaScript, API and Markup. A stack is simply a combination of several technologies. You may have heard the term technology stack as a name for a collection of technologies that work well together? JAMstack is such a technology stack.

Markup in the form of HTML arrived in 1991, JavaScript in 1995 and APIs have existed since the early 1950s even though they looked very different back then. So why this hype around JAMstack? It rather feels like someone has gotten a touch of nostalgia and suddenly wants to build websites the way they did in the 90s. And the fact is that it’s not such a bad observation! The purpose of JAMstack is to increase performance, security, scalability and robustness by making things a little less complicated with fewer moving parts.

In a sense things were a bit less complicated before. At the same time the technology was very undeveloped. Today it is not. So even if you use an old principle to build websites, today you have more and far more advanced tools that allow you to automate much of the work that was previously done manually. This is a major contributing reason why the technology has become relevant again.

So what is JAMstack really?

If you’re content with the short version, here it is:

“Building pages with a static site generator, serving them via a CDN, and using JavaScript and APIs for dynamic content.”

But if you’re a bit more curious than that, feel free to keep reading.

The benefits of JAMstack – we list four of them

1.    Increased performance

On a website that runs on a traditional CMS, e.g. Umbraco, Episerver or Wordpress, the pages are generated by the server at the moment they are requested by visitors. It doesn’t take especially long – we’re talking milliseconds – but the web server still has to fetch data from a database and generate a page from that data using a page template as a starting point. That takes longer than simply serving an already finished file. And if you have to generate the page dynamically you also need a server that can execute code in real time, a database where you can store data, and so on. All of that has been removed (or rather relocated) in JAMstack. You serve already finished files from web servers that don’t build pages or execute any code at all.

That doesn’t mean you don’t have to generate pages when using Jamstack, only that they are generated in advance when the code is saved and built. They therefore exist as finished files and can be served immediately when requested.

In short: a page in JAMstack is built in advance when the code is saved and built, not at the moment a user requests it.

2.    Simpler, faster and cheaper hosting

By removing much of the complexity on the server side by serving static pages (HTML files) we can use entirely different hosting solutions. Instead of placing pages on a dynamic web server at a web host, you can place them directly on a CDN (Content Delivery Network) together with other static resources such as images, stylesheets and script files. A CDN is not only a significantly cheaper hosting solution, it is also much faster and more reliable. (If you want to know why, feel free to check out our other article about CDNs).

3.    More secure

JAMstack is generally regarded as a more secure architecture than sites built on pages generated by dynamic scripts that run on the server side. The argument behind this is that you have removed much of the "moving parts" by serving simple files and thereby reduced the number of potential security holes that a complex architecture can expose.

To some extent that is true, but as soon as you introduce dynamic features based on user interaction you will also open up potential security vulnerabilities. And dynamic features can exist in Jamstack too, although they are exposed via an API rather than directly in scripted pages. So an architecture alone cannot make a site secure. It is rather the awareness and knowledge of those who develop the site combined with a technical architecture that together guarantee secure websites.

4.    Scalability

If you have your web pages and other files on a CDN you have scalability by default because CDNs are built specifically to handle large variations in traffic and have implemented techniques to handle this with robust infrastructure, data hosted physically close to the user (in the same city, country or continent) and a strong focus on caching data. With a traditional website you might have to proactively ramp up server performance in advance if you expect high load. You don’t need to think about that if your hosting is on a CDN.

How do you create dynamic features?

So far we've talked a lot about the pages themselves, i.e. the M in JAMstack (Markup). We've established that these are static HTML pages generated when the code is saved and built. But if the pages are already generated in advance, how can you provide dynamic features that users can interact with? If, for example, you have a page that lists products, the user may want to sort them by price or filter them by brand or color. On a static page this is impossible. This is where the J (JavaScript) and A (API) come into play.

Even though an HTML page is static, it can still have JavaScript files attached to it. The scripts can in turn do everything needed to implement various forms of dynamic functionality: handle user interaction, generate dynamic markup (e.g. a sorted product list), fetch and save data via an API, etc.

"If the pages are static, how do you add dynamic features?"

We mentioned earlier that dynamic functionality and data storage had been moved away from the server that serves the web pages themselves in JAMstack, and that's true. But that doesn't mean you can do without it. You will still need to fetch and store data. All such functionality has been moved out to APIs. So instead of the data being received by the same server that serves the web pages, it is sent via an API from an application server that only exposes an API. There you can have both business logic (in the form of executable server-side code) and data storage in the form of databases. And this is important to understand: you will not, in any magical way, avoid server-side technology just because you use Jamstack — you've only moved it out to a separate API.

What is needed for JAMstack?

It may sound like Jamstack is the name of a product or a specific technical platform, but it isn’t. It’s just an architecture. You can therefore use many different combinations of more specific platforms, frameworks and services to build a web with JAMstack. But you will still need the following categories of platforms:

• A site generator
  A site generator is the platform responsible for generating the actual HTML pages that make up the website. What it does is roughly what a modern web server does: it takes content and page templates and puts them together into pages.
• A JavaScript framework
  If you want any form of interactivity you need JavaScript. Of course it’s perfectly possible to develop this functionality in plain JavaScript without any framework support, but it will be challenging and time-consuming. That’s why people usually use some kind of JavaScript framework, e.g. React or Vue. In many cases the site generator and JavaScript framework are bundled under a common name, e.g. Next.js or Gatsby.js, which are two of the largest platforms.
• Probably a headless CMS
  The role a headless CMS plays in Jamstack is as an API. It’s the place where you upload your images, write content and configure settings. This content is then exposed via an API that can be consumed dynamically with JavaScript or directly when the pages are built and become part of the pages on the website.

In addition to this there are two other categories of platforms/tools that are likely needed:

• Source code storage and version control (a repository)
• A solution for builds and deployment

However, these are not unique to Jamstack but are needed regardless of which type of architecture you choose for your website. Sometimes they are separate products, sometimes several different product categories are bundled into the same platform, e.g. where you can both manage content (CMS), build code and publish it out to a CDN.

Two examples of using APIs – in different ways

Normally when people talk about APIs they think of a place where you can fetch and save data dynamically, usually initiated by some form of user interaction. It can, for example, be in a search field: the user types something into the field, the API is queried, and if there are any matching search results you get a response. That's an example of dynamic use of an API.

But if you use a static site generator you can also use the API statically, in connection with generating the pages. This is especially useful when the content you fetch from the API doesn't depend on any form of user interaction, i.e. it's the same content all the time regardless of what the user does on the site.

Say, for example, that you create a page in your headless CMS. You write a heading, upload an image, paste in some text you've written and add a handful of links. All of this is content that won't be affected by user interaction because it's fixed on the page. It then feels unnecessary to fetch it dynamically every time a user visits your site. So instead of fetching it every time, you make sure the content is fetched once when the page is built. It then stays there until someone goes in and changes it. The page is rebuilt and you get a new static page.

So a website built with a static site generator is both static and dynamic at the same time. The files that are served are static, but their content can be more or less dynamic depending on how you choose to use your APIs.

When is JAMstack not suitable?

There is a clear scenario where JAMstack is directly unsuitable as an architecture, and that is when you have a huge website. By huge we mean a site with 100,000 or more pages. Generating and storing all those pages as static pages can then become a problem in itself because it consumes a lot of resources, both in terms of time and processing power. In that case it is probably smarter to look at a database-driven architecture.

”JAMstack is not suitable for enormous websites”

One can also wonder whether JAMstack is suitable if you have a website where much of the content is behind a login and is largely tailored to the individual user. In that case some of the point of generating static pages disappears, since the content by definition must be dynamic precisely because it is individualized. It is, of course, still possible to set up a static framework around the site and use APIs to fetch all dynamic information, but it is not a scenario where Jamstack really stands out.

In conclusion

The more you read and learn about the JAMstack, the more you realize how closely tied it is to CDNs. It is in the combination of static files and a CDN’s ability to serve them quickly, cheaply and securely that the greatness of the JAMstack lies. There is also something appealing about returning to the simple, robust nature of static files while still being able to offer a modern and technically advanced user experience. As we noted, however, it is wrong to believe that a website built on the JAMstack completely lacks dynamic server technology; rather, the separation between files and APIs has made clearer what is frontend and what is backend.

Also read