In this tutorial, you will learn about the benefits of using a JAMStack architecture. JAMStack really is a massive game-changer in terms of web development. I have spoken to a lot of people around JAMStack and from what I have noticed, it is easy to mistake the main benefits of JAMStack. As a spoiler, if you assume it is about the programming language you are wrong, it's about infrastructure 🤔
I personally didn't process the real benefits of this architecture when I first heard the term JAMStack. I didn't get 'it'. This is why I have written this post. The aim of this post is to explain the benefits of JAMStack in as non-tech jargon way as possible. By the end of this guide, I am hoping you will understand how JAMStack architecture can cut down your development teams built time and can also potentially save your company significant money. If this sounds inquiring to you, read on 🔥🔥🔥
JAMStack Vs Single Page App
From a first glance perspective, the true power of what JAMStack means can easily be missed. JAMStack stands for Javascript, APIs and Markup and the really important part of that equation is Markup. If you assume the term is just about building React websites, you are missing the point
When you build a website using a language like React.Js, or Vue.js, you can build it either using a single-page application architecture (SPA) or a JAMStack architecture. An application can not use both architectures at the same time. The architectures are similar in nature and at first, glance might seem the same, however, there is a fundamental difference. Understanding that a JAMStack website follows a different architecture compared to a SPA is an important first step 👣👣👣
A SPA is an application that is built within a clients browser. When a site visitor requests a page, the mark-up and Javascript are sent to the requester's browser. The web page is then built at run-time. Pages can potentially be cached using server-side rendering (SSR) to improve performance, however, pages are fundamentally still built at run-time when requested.
In this sense, a SPA and a website built using server-side technologies are very similar. The main difference is the programming language and where that code is executed. If you like C# you will build server-side websites. If you like React you build client-side websites.
JAMStack completely re-thinks how your website is hosted and for me, it's this difference in hosting that is the important thing. All JAMStack sites are built as HTML pages. To create a JAMStack website, you need to use a static-site generation tool, like NextJS or Gatsby. These tools take your website and convert it into HTML at build-time. As the pages are built at a different point in time, this changes the game.
To hopefully explain the point in a different way, I want to talk about SvelteJS. I spent a few months learning SvelteJs in 2021. The main reason I wanted to learn it is because it has different capabilities compared to ReactJs. You can do things in Svelte that you can not do in React. The reason for this is that it uses a different architecture, the same is true for JAMStack websites. A JAMStack website allows you different capabilities compared to traditional web hosting and some of these differences are really interesting 🤔
Classic Architecture Vs JAMStack Architecture
Regardless if you want to build a SPA or a server-side powered website, your infrastructure architecture will look roughly like this:
Let us think about what's problematic with this architecture:
It relies on code to work at run-time: If you make a change in the CMS and the content causes a bug in your code, the whole site can break instantly
If your CMS server falls over your website will not be available: This one is simple enough, CMS server down, website down ✔️ Some companies may pay for a disaster recovery CMS server to prevent this from happening.
If you get a sudden load in traffic, your server may struggle: When your site encounters a high load of traffic, your page performance might be negatively impacted. To cater for these spikes, you may need to pay for lots of servers that sit idle most of the time. You could automatically scale servers up, however, you still need to pay for them while they are running. In a large enterprise company, these costs can easily be 10-20K a month in server bills!
Testing Is Hard: In classic architecture, a page is built on a server. No two servers are exactly the same. Every server will have slight nuances. Each server will have a unique IP, they may also have different configuration settings, CMS data, databases, caches, etc... The result of these differences is that pages can render differently depending on which server the request is sent. A page that looks great on staging might be broken in production. If you do not have exactly-like-live environments no matter how good your testing process is, bugs can appear on your live site.
Long Deployments: Traditionally the process of deploying code into production can take a while. Even if your site is small and fast, you might need to warm up a cache, generate SSR and do lots of other pre-tasks. This means deployments can take a long time. I've worked on a project that could take up to an hour to release. If you use a web app within a cloud provider like Azure, warming up the server and releasing it can take time
Web Vital Impact: In order to render a page, some code needs to run. This takes time and will impact your page performance. To counter this, developers need to implement things like caching or dynamically call APIs after page-load. Calling data after page load can impact like Cumulative Layout Shift (CLS)
Now, let us compare this to a JAMStack architecture and see how it changes things:
In a JAMStack powered website, your webpages are not built at run-time, they are created at build-time. This fundamental difference makes quite a big impact. The HTML pages are generated, either manually when you decide to release your site, or, automatically whenever someone publishes a change within your HEADLESS CMS via a webhook. Once a build is triggered, a call is made to the headless CMS to get all the page data. These pages are then converted into static HTML pages. It is up to you to decide if you want to automatically roll out these changes instantly, or, bubble them up and release them in your own time.
The good thing about this process is that you can still use React or Vue to hydrate the page in the requester's browser, just as you would in a SPA. You get the best of both worlds. If you have dynamic content that changes a lot you still may want to get things in real-time rather than statically build it in, the choice is yours ✔️. When you decide to release your site, you set the output folder live. The HTML pages are pushed to a CDN, also known as edge nodes. Job done💥
The Benefits Of JAMStack
As you can see, the steps to release a JAMStack site are pretty different. This difference provides a lot of benefits that might not be initially obvious and in this section, I will cover some of them:
If your CMS server is down, who cares? None of your live website traffic needs to communicate with the CMS anymore. The benefit of this to your architecture is more reliance
Improved performance: Static HTML Pages are quick. Nothing is faster than static HTML, so your web vitals will be good
Screw Caching: Setting up caching correctly can be hard. Getting things like SSR correct can take time and effort. In a JAMStack architecture, you do not need to spend lots of time writing and testing the cache, as it's all pre-built HTML.
Easier Deployments: The output of each build, will be a complete point-in-time set of HTML pages for your site. Rolling back to a previous state in time is as easy as clicking a button. Regardless if content has been updated in the CMS, your new code does not work, within an instant you can undo everything. Tools like Netlify will store all your build file history, so in theory, you could roll your site back to 2 years ago in an instant! The more useful part is that if there's a bug in your latest release, you can roll back to exactly the same state as before without worry.
Cheaper Infrastructure: As you are just hosting HTML, your servers do not need to constantly process pages. This means you need fewer servers running. This saving in servers can save a company thousands a year!
Improved Testing: Before releasing you can test the static files you will make live. No more like-live environment bugs.
I'm hoping you can see the power of JAMStack is not about which programming language is best, it's about the improvements to the infrastructure and your software development process. It's this change in architecture and the new capabilities that are really interesting. I think nowadays most companies who talk about HEADLESS expect JAMStack capabilities. The saving in server costs alone is definitely worth the cost and effort of undertaking a new website migration
Everyone has their own favourite programming language. If you take programming languages out of the mix, what's not to like? Due to the combination of static HTML and CDNs, JAMStack sites are faster. These sites are also more stable, as there is no reliance on the backend. Due to the nature of atomic deploys, all your sites content and pages are self-contained within a point-in-time backup within a single folder. This means releases are less risky. The best part is that due to how good the tooling is around the JAMStack, you can build a JAMStack website from scratch and have it hosted for the world to see in under 10 minutes. I have made a YouTube video to prove this point!
The Downsides Of The JAMStack
As with any change in architecture, you will be faced with a different set of challenges. No architecture is perfect and each one has its own trade-offs, considerations and limitations.
The first consideration is the time it takes to build your static pages. If you have one million pages, it will take a period of time to turn them into static files. To deal with this challenge, tools like NextJs have released on-demand static file generation:
Using this technique, you define in code your sites most important pages. These pages will then be built at bulid time and the rest are ignored. These less important pages will be built and converted to static HTML on the first request. The HTML file is then added to the CDN layer and the page does not need to be regenerated. If we are honest with each other now, out of your one million pages how many of them are viewed all the time.
Monolith Vs MonoRepo: In my opinion, if you have a single website that has millions of pages, your architecture is wrong. We all know that big monolithic server-side applications are not ideal. Whole architectures and patterns, like micro-services and service-oriented architecture, have been invented to help us keep things small. In general, small is good 🤏
The same principles should also be applied to your website application. Instead of creating one massive application, you should consider using a micro-frontend architecture, maybe using a mono-repo to split your website into smaller applications. Splitting your single site into lots of smaller parts has lots of benefits. Using a service-mesh like Google Istio with Kubernetes will allow you can make your website look like one thing, however, in the backend, it can be built from lots of smaller applications 🤯🤯🤯
This topic is a video and blog post on its own, however, if your concern around JAMStack is size, research this topic! The point of this article is that splitting your site up also removes the challenge of having to build too many pages at build-time! The other main areas where JAMStack is not as strong are on sites whose content updates all the time. If your page needs to call data in real-time, a SPA is probably more suitable.
The Future
Asides from all these infrastructure benefits, there are also other areas in web development that can be re-thought. Personally, I think these areas are going to be really interesting in the next few years. As you static build pages, you can do things like personalisation and A/B testing in the edge. No more flicker effect that all frontend experimentation tools suffer from. The user can be bucketed at the edge and the static page that contains the matching variation can be returned instantly. The same is true for personalisation, personalisation at the edge layer is another real possibility. There are already a few companies out there that are doing these types of things, however, as the architecture matures I am sure we will see lots of other cool things.
I am not a mystic met, or a clairvoyant (if I was, I'd have won the lottery and not be writing this) so I don't know how tech will change over time, however, I am certain of one thing. JAMStack architecture allows us to work with websites in a new way. This new way of building things will lead to new innovations.
You now know JAMStack is not about building a site in React or Vue. There are real business benefits and potential savings in cost by adopting it. Happy Coding 🤘
