Jamstack 101 - all you need to know

Adam Leszczyński

August 19, 2021

13 min read

Jamstack is a modern approach to creating fast, easy to maintain and secure websites and web applications. It is not a specific set of technologies or tools - these are selected individually for each project.

The popularity of this solution is growing at an express pace, which translates into a whole ecosystem of solutions, of which there are more and more.

To understand how beneficial this way of implementation is, it's enough to look at a few large companies that are already using this solution, e.g. Netflix, Spotify, Braun, Airbnb, Nike or KFC.

Whenever I refer to traditional server architecture in this text, I will mean the so-called LAMPstack, which has been the standard for developing websites and applications for more than a decade.

In this text I will focus on explaining what exactly Jamstack is, what are its key elements, how the ecosystem associated with it works, and I will present what advantages it provides as well as what are its disadvantages.

Etymology of the word Jamstack

For a good start, let's decipher the acronym itself. JAM stands for JavaScript, API, Markup, while stack, in this case meaning technology stack - a term that denotes a collection of technologies combined with each other to create a particular project.

JavaScript

Undoubtedly one of the most popular programming languages in the world. Created 25 years ago, it was initially used to create pop-ups on websites (aka popups) that annoyed users. Today it is absolutely crucial when it comes to the internet as we know it. An essential component of any web application and an important aspect of websites. It is the only programming language that is supported by all modern web browsers. It allows you to write code that is understandable for both the server and the client (the web browser). It is so versatile that today it is used for machine learning, writing games (not just browser-based ones), or even for creating space rocket interfaces.

In Jamstack, it is JavaScript that is responsible for creating all the business logic and giving dynamic (which we will talk about later).

API

An Application Programmable Interface, or API for short, is a set of rules that define how an application can communicate with another application. The word interface is key here, because it simply means a way of communicating Example? You want to post currency rates on your site, which you know change every day. Instead of entering the exchange rate of a given currency on your website every day, you can use the API, e.g. National Bank of Poland, which will return the exchange rate of a given currency updated every day, which will allow you to display the current exchange rate on your website, without your intervention. The API can also be used to send emails or SMS messages, display social media posts, handle payments and much, much more. I venture to say that there is nothing today that we can't use the API for.

Markup

The word markup informs us that the created website or web application has a pre-drawn skeleton on which we can operate with various data, i.e. substitute texts, images or even create whole subpages. The term refers to an extension of the abbreviation HTML - HyperText Markup Language, which is the markup language that makes up all the web pages we are able to visit. The Markup is the first thing a web browser receives when it starts displaying a website to the end user. It is used to create the entire foundation that, when combined with the CSS (Cascading Style Sheets) language, gives the appearance of our website or application.

The essence of Jamstack is that markup is served (at least mostly) as static files, which creates an advantage over traditional server infrastructure (more on that later).

Key elements

With the definition behind us, we will now look at the key aspects of the Jamstack architecture. An important part of understanding why Jamstack gives us an advantage is understanding what static content and dynamic content are, how servers display what we see in our browsers, and how client-side rendering differs from server-side rendering.

Rendering in two editions

Rendering is the process by which the browser paints pixels on our screens to create a coherent image of a web page or application.

When we type a domain name in the browser and click enter, we are actually sending a request to the server behind that domain. Depending on which server we send the request to, 2 things may happen:

1. We will get ready-made static files that have been rendered on the server side,
2. We get guidelines for our browser, how it should process and render what the server we're connecting to tell it to do.

Of course, this is a very simplified description, and the whole process of displaying web pages is much more complicated, and it's a topic about which one could write a book.

In option number 1, which shows the Jamstack approach, the whole page, before placing it on the Internet, is prepared to serve only (or mainly) static files. Making a query to the server on which such a page is located, we receive an answer almost immediately. This is possible because the server already knows what exactly the web page we want to visit should look like. This is called server-side rendering.

Option number 2 on the other hand, using the classic server infrastructure, is a bit more complicated. The server processes the query, and often sends a query to the database as well. Then it renders the whole page on its side, returns it to the client (web browser) and only then the browser can take care of the rendering process on our device. This is why we often have to wait awhile for content to load on these types of pages. This is an example of dynamic content creation. Each user gets a de facto different page - different because it has been rendered with the execution of the request to the server. We call this client-side rendering.

Modern tools allow us to mix the two approaches together in such a way that part of the site is dynamic and part is static. This can be remarkably useful in some cases.

Static is the new Dynamic

It used to be that by creating a simple web page using HTML and CSS and uploading it to a server (such as Apache or nginx), we had no way to edit that page without directly interfering with its source code. So every change required manual work at the source. As you can guess - it was not the most convenient solution for website owners.

Later, monolithic CMS (what is a CMS I'll explain in a moment) were created, such as WordPress, on which both developers and content creators worked. Over time, the WordPress ecosystem has grown to the point where there are tools that allow you to create pages without coding skills, called Page Builders and a bunch of plugins that allow you to de facto turn a website into an application by adding complex functionality.

With the growing popularity of JavaScript and its widespread adoption in web browsers, new possibilities were born. Content displayed on pages could be rendered dynamically - it no longer had to be part of the web page's source code. Because JavaScript runs in the browser, content could change without having to reload the page. This opened a lot of doors for developers, who could use all sorts of APIs in a trivial way.

On the wave of this popularity, Jamstack was born, which assumes that pages and applications created using this convention are almost entirely static, except for places that require dynamic data. In a telegraphic nutshell, dynamic data is data that can change conditionally if certain circumstances arise.

Static Site Generators

An important part of the Jamstack world is Static Site Generators, or SSG for short. They are frameworks that deal with optimizing and reducing the final size of the created project by generating HTML, CSS and JavaScript files.

frameworks are fundamentals for building applications. They define the structure and basic functionality, which we can usually extend.

Their main feature is that the code that the developer writes is completely different from the production code that the end user has to deal with. This difference comes from the fact that Static Page Generators have the ability to generate applications, in a process called building .Once the process is complete, you get optimized static files that can be served to users as a functioning website, eCommerce store, or application and don't require complex server configuration to do so.

So to make any change to a website or application, you need to run the build process, which usually takes a few tens of seconds upwards, depending on the number of subpages. Done. With proper configuration, our change is automatically visible on the web.

For the client this process is super-simple and usually comes down to click one button in a special panel. Thanks to this solution, the person who edits or adds content to the site is not able to break anything, and the process itself does not require any technical knowledge.

It is worth mentioning that Static Page Generators are not an inherent part of Jamstack. You can also create projects in this convention without using any framework, using "pure" JavaScript. However, this is usually not an optimal solution. Let's take for example a product catalog of an online store. Instead of creating a subpage for each product manually, we can create one template for such a subpage, and then, using the Static Page Generator, substitute the data to the template and generate subpages that will look the same, but will have different content. In practice, this process comes down to clicking the "add" button in the CMS panel, filling in the product information fields, saving the changes and clicking the button that starts the build process.

Content Management Systems

Okay, we already know how Jamstack works, how pages and applications are built using it, and how it differs from traditional architecture. I've also written about dynamic content in this type of projects - so you may rightly ask, how you supposed to add or edit content on a page that was generated as static files?

This is where CMS (Content Management System), a term familiar to many, comes to the rescue. By definition, it is an application that is used to manage content on a website, store, or app.

The most popular CMS in the world is WordPress and it is very possible that you have heard of it or even worked on it. WordPress is an example of a monolithic CMS, meaning that the server code (back-end) and the code visible in the browser to the user (front-end) are closely and inextricably linked. This means that they exist on the same server as one big application.

front end → everything that is visible to the user when they enter a website, web application, and mobile application. As a rule, it is responsible for the visual layer.

back end → code that runs on the server side. Everything that the user doesn't see, but what happens "underneath".

Content Management Systems that don't have a head

Jamstack assumes a complete separation of back-end from front-end. In Jamstack applications we can choose any back-end, which, using API and JavaScript, will communicate with the page or application we are creating and use data or functions of such API.

An example of such a back-end might be Headless CMS. This is the opposite of traditional CMS systems, such as WordPress or Drupal (although those can also be used as Headless CMS, more on that in a moment). The difference is that Headless CMS- are completely independent of the front-end and do not rely in any way on the templates they generate themselves. Instead, they are just a place where we store the data that is retrieved by our application and inserted into specially prepared places in our markup (template).

Headless CMSs give us the freedom and most importantly allow content creators to focus on creating content without worrying about messing anything up. They also speed up the editors' time because their job is just to fill in fields, whether text or graphics, without interfering with the source code of the application itself.

Examples of such CMS could be DatoCMS, Forestry, Sanity, Contenful or Strapi.

I mentioned that WordPress or Drupal can also be this type of CMS. In what way? Well, very simply - we use them as a store of content.This content can be accessed by JavaScript, which, using API (of that CMS), implements this data into our markup, (template). With this solution, people who are used to adding content in WordPress don't have to give it up, and the site owner can enjoy the benefits of using the Jamstack architecture. However, keep in mind that WordPress requires a constantly running, classic server to host this application.

Many sources at once

CMS seem to be the most popular choice when it comes to our data source, but they are not the only choice. Such a place can be services such as Notion, Medium or Airtable. Data can also come from classic databases or services like Google Docs. For e-commerce stores, we can pull products from WooCommerce, Shopify, BigCommerce, Stripe or Snipcart.

One of the things I like most about Jamstack is that the approach is completely indifferent as to the source of the content. As long as some service provides its API, we can use it as our CMS and pull data from it. There's also nothing stopping us from having several of these sources at the same time. However, the more of them there are, the longer it will take for those APIs to communicate with the project we're creating.

Of course, nothing prevents texts and images from simply being part of the source code of the page, as is the case with the page you are reading these words on. The source of the content for this article are Markdown files, which have the extension .md and are an incredibly versatile file type - it is easy to interpret for both humans and web browsers. It is worth, in my opinion, at least knowing about its existence.

The benefits and advantages of Jamstack

Speed

Combining pre-generated static files with CDN makes Jamstack pages and applications incomparably faster than their traditional counterparts. And you know who likes fast sites? Yes, Google. It turns out that the speed of the site is the second factor, after the content itself of course, that determines the indexing of pages in this search engine.

CDNs (Content Delivery Networks) are global networks of distributed (often worldwide) servers that work together to rapidly disturb content on the Internet. For example, all social networking sites use CDNs to host photos and videos. If you've ever tried to send a direct link to a photo (by right-clicking and choosing "copy photo address" or "open photo in new tab") you might have noticed that part of such a link contains the abbreviation "CDN".

It may seem like 3 seconds this way or 3 seconds that way doesn't matter, but studies of companies that have decided to improve the performance of their websites or apps show that it's not just Google that likes fast sites - users do too. They are much more likely to stay on a website or use an app if it runs fast. Long load times scare users away, reducing the chances of them seeing what you want them to see.

Stability

If you've been maintaining a site on WordPress for a long time, there's a good chance you've encountered a stability issue. You log in to the dashboard, notice a red icon indicating that a plugin update is available, click "Update" and suddenly it appears that the whole site has stopped working.

The most vulnerable parts of website and application infrastructure are servers, plugins and databases, and Jamstack allows you to get rid of those elements and focus on the project itself, not on the things surrounding it.

Security

Since we don't have a server or database, we also eliminate the security issue to a large extent.

The vast majority of hacking attacks that aim to steal user information are conducted through databases.

We also do not have to worry about the server itself, which in the case of shared hosting, is much more prone to failure, than dedicated hosting.

Scalability

CDN guarantees almost unlimited scalability, so in practice, with the Jamstack approach you can forget about problems with excessive traffic on our site.

Since static files do not require a traditional server, the cost of maintaining Jamstack-based projects will be much, much cheaper than traditional hosting or VPS. It is usually the case that for small to medium-sized projects, it costs us absolutely nothing to maintain a website or application.

Costs

Start small and go big. Nowadays, you can put your website or application on the Internet without any financial investments. Thanks to CDN networks we can start completely free of charge, without generating any additional costs, and as our enterprise grows, and we generate more income, we can think about moving to paid plans of particular services.

Versioning

An important aspect of any project is backups, in case something goes wrong, or you just want to roll back to a previous version of the project. In the programming world, there is a software called Git, which is described as a "distributed version control system". It is an essential tool for any programmer. Thanks to it, we are able to save all our changes in the code and, if necessary, restore a given version of the project with a simple command.

In Jamstack, Git plays the role of a backup medium. Whether we want to change the hosting of our application or restore its previous version - we have this possibility in a very simple and convenient way.

Is this solution without flaws?

No, it absolutely is not. There are no perfect solutions.

• The disadvantage may be that you will need a specialized person or team to create and possibly expand or make fundamental changes with this type of project.
• Additionally, not every project will be possible to complete this way. Some websites or applications simply will not be able to be generated as static files. If the content in such a project will be displayed depending on which user is currently logged in and will be in constant motion (as is the case on social networks or stock markets, for example), then using Jamstack will not be the best idea.
• If you are planning to create a really huge website, which will contain thousands of different subpages, you have to reckon with the fact that the process of building will take from a few, sometimes even up to several minutes. Fortunately, there are solutions to this problem that rebuild only the part of the project that has been changed or added. There are also Static Page Generators specifically designed to deal with huge amounts of sub-pages and content, such as Hugo.

The Future of Jamstack

The future of this approach is bright, thanks to the growing availability of tools that allow you to create in this convention. For example, giants such as Microsoft and Cloudflare have recently started offering their tools to host static pages for free.

Another trend that appeals to Jamstack is the so-called. Serverless, an approach that removes the burden of configuring and maintaining servers from developers in favor of Cloud Computing, such as Amazon Web Services, Microsoft Azure or Google Cloud Platform.

The number of companies that specialize in solving problems using API is also growing. These are problems like - payment processing, user authentication, Push notifications, email sending, contact form handling or bringing search engines directly into a website or e-commerce store. And if you look at it from the security side, it makes a lot of sense. For example, instead of dealing with the sending of e-mails yourself, you can entrust it to a company that specializes in it, has a product available on the market for years, and a dedicated team with support that watches over the whole thing at all times. The chance of failures is then significantly lower.

Summary

Jamstack is a technology stack based on client-side (browser) JavaScript, reusable API, and a pre-generated or self-created Markup. It doesn't force developers to use specific technologies, there is almost complete freedom as to the tools used. Thanks to that projects can be even better adjusted to client's needs and requirements.

Thanks to the use of static files it allows creating projects quickly and cheaply in maintenance, which lets scaling in the case of increased user traffic, and the lack of a server and database to a large extent exclude security problems. The use of external API, on the other hand, allows you to add new functionalities at a low cost and in a short time.