Jamstack: another buzzword or the future of web development?
Serge KorzhReading Time: 6 minutes
The ever-changing world of web development has produced numerous terms, concepts, and technology trends over the years. Among them, Jamstack has definitely been one of the hottest newcomers. But what is Jamstack and should we pay attention to it? Let's have a look and figure it out together.
Do we need another term like the Jamstack?
First of all, what is Jamstack? It's not a new JS framework, nor a technology stack, as it appears from the name. The term was coined by the cloud computing provider Netlify back in 2015 to have a name for a paradigm shift they noticed in web development. Initially, it was called "the JAM stack", where JAM stood for JavaScript, APIs and Markup, contrasting it with the popular AMP (Apache, MySQL, PHP) stacks, the MEAN stack, and others.
Over the years, the concept grew out of its original acronym and now means something more than just another technology stack. The official website describes Jamstack as "an architectural approach that decouples the web experience layer from data and business logic." Notice the word 'decouples'. Jamstack is strongly related to the microservices architectural approach, but unlike it, Jamstack has a strong focus on the web developer workflow and the website lifecycle. It is an approach to building and delivering websites, not just an architecture. So what exactly makes a website Jamstack?
The microservice architecture is a key element of Jamstack
Markup is pre-rendered with content baked into it
Instead of worrying about server uptime, caching, cache invalidation, deployment and scaling, security, and all the other issues that come with having a web server processing requests, a Jamstack website pre-renders the markup (HTML) of the website at build time using a Static Site Generator, and serves it as static assets on a CDN.
Build and deployment automation
You might've thought "Wait, so Jamstack is just a fancy way to call static websites? I thought they're a relic of the past!" That's where the biggest enabler for Jamstack – automation, really comes into play. Of course, directly editing HTML of a page in order to replace a logo or update product attributes would be infeasible. Instead, every time some part of the website content is updated (e.g. using a headless CMS such as Strapi), a webhook is fired, which triggers the build and the updated markup is pushed to the CDN in one atomic, immutable deployment.
Git-based workflow and Config as Code
This may sound like an obvious best practice for any software development project, but with Jamstack, having all of your source and configuration files live in a Git repository is a must. This enables the streamlined automation of CI/CD we touched on before. I mention Git and not just a version control system because most of the CI/CD tooling is centered around the Git-based workflow and won't work with other VCSs.
Leveraging APIs for dynamic content
While pre-baking a lot of the content at build time can go a surprisingly long way, client-side rendering can be used for the bits of your pages that require highly dynamic or personalized content. This is usually done by packaging a specific part of your business logic into a separate API. This can take many forms – a custom microservice, a headless eCommerce platform like Shopware, a serverless function, or a 3rd-party API of a SaaS solution.
“Jamstack is an architectural approach that decouples the web experience layer from data and business logic, improving flexibility, scalability, performance, and maintainability.”
Should I use Jamstack for my website?
We discussed the components of Jamstack. We now know that a Jamstack website isn't just a static website, it can be highly dynamic by utilizing a frequent build and deploy cycle, and client-side API calls. The Jamstack approach can be combined with other web development patterns like the PWA and SPA.
That's all well and good, but why should you consider it for your next project? Does it pay off migrating your existing website to Jamstack? Let's go over its key benefits.
Performance
When your website lives entirely on a CDN, a user gets the page served from a local CDN node faster than any server infrastructure would hope for. This means better UX, SEO, accessibility, and lower hosting costs.
But what about the build step? What if you have millions of pages and you're updating content all the time, wouldn't it cause a huge overhead? Indeed, this used to be an issue with older static site generators, but they became much smarter about optimizing the builds, and frameworks like Next.js now offer Incremental Static Regeneration, allowing you to generate new or updated pages after the build step. With more granular control over what content gets refreshed when and under what conditions, such tools let you optimize every bit of your website content to use the best applicable update strategy.
Scalability
You don't have to worry about sudden spikes in traffic, as the bulk of your website is inherently scalable! Scaling is essentially localized to a few self-managed API services, if you happen to have any. And you don't have to scale everything at once – one API responsible for a high-load functionality can be scaled independently from all the rest.
Security
With Jamstack, the page rendering and page serving steps are separated and don't share the same environment. Server-side tasks like database querying are performed during the build step, when the pages are rendered. Thus, many types of attacks (e.g. SQL injection, RCE) are impossible to carry out simply because the build environment (where such vulnerabilities might exist) isn't exposed to the public. The vectors of attack are narrowed down to specialized APIs exposed to the client, and in case one is compromised, it doesn't necessarily put all of your website in jeopardy. On the other hand, when a part of the stack of a monolith application is compromised, often the whole application is compromised.
Maintainability
Just like with microservices, a Jamstack website is much easier to maintain in the long term. Yes, developing and integrating several standalone services comes with an additional overhead, and adds complexity to the initial project setup. But a website (hopefully) lives for a number or years, and updating or changing parts of it is a necessary part of its lifecycle.
With a monolith application, migration from a legacy system to a newer one is a tedious and risky process. In contrast, a Jamstack frontend can be rewritten completely separately from the rest of the services used on your website, and the services themselves can be replaced independently, according to your changing needs. This means there is no all-or-nothing situation when you have to lock yourself into a single platform or a service provider.
Reliability
It's always better to catch errors as early as possible. With the build step happening in your own, controlled, private environment, you're always certain that your website won't show a 500 Internal Server Error to your users, just because the web server didn't anticipate a database error in one part of your application.
Moreover, you can deal with some services being unavailable or broken without stopping the whole website. Let's say you have user reviews managed by a custom service and its server suddenly went down. No big deal, as the rest of the website will function just fine while you're fixing the issue!
The 500 Internal Server Error is a popular "feature" of server-side rendered websites. Source: Symfony docs
When Jamstack isn’t a good option for you
The advantages of the Jamstack approach seem great. But surely it doesn't fit all use cases, right? Here are some scenarios when you might opt for another solution.
Internal app / no public-facing content
You're developing an internal tool, or a web app for a closed user group. The traffic is localized and more predictable, the app is fully interactive, and you want to host it on an internal server to manage it yourself. Clearly, there is no need to serve pre-rendered pages from a CDN.
However, you can still choose a framework like Next.js that allows hybrid static and server-side rendering in case you want to optimize or expand your app, and utilize the other aforementioned Jamstack practices.
Technology stack constraints
If you are limited to using specific technologies, service providers, or hosting, you might simply not have the access to the right tools to use the Jamstack approach. That being said, you don't need to use a modern JavaScript framework like Nuxt or Gatsby to build a Jamstack website. You can find a Jamstack-friendly web framework written in nearly any language, examples include Hugo (Go), Jigsaw (PHP), and Statiq (.NET Core).
No issues with the existing solution
Say, you have a WordPress website, and the following applies:
- the standard features plus a few plugins provide exactly the functionality you need (do they?);
- you don't expect any need for scaling the website (are you sure?);
- you don't mind keeping WordPress and all the plugins up to date yourself (do you?),
- you have a great team of WordPress specialists.
In short, you're very happy with how things are, that's great. Still, you can consider trying out Jamstack for a page or two, using WordPress as a headless CMS, while proxying the rest to the server. Or explore one of the WordPress-to-static tools like Shifter that bring the best of both worlds without the need for a costly migration.
Final words
If we take a look at the bigger picture, Jamstack isn't a revolutionary concept, but rather a new name for a combination of established practices that go well together. Microservices rather than a monolith, doing more work at build time rather than runtime, Git-based workflow and CI/CD automation – these are well-known patterns in software development.
Your specific case might not call for a typical Jamstack technology "stack", but this doesn't stop you from applying the Jamstack approach when designing your DevOps processes and application architecture. While Jamstack hasn't yet become the new standard, nor is it certain it will, the general trend is here to stay – removing the complexity of web apps where it's not needed. The trend goes hand in hand with the concept of Green UX discussed in Alicja's blog post.
I hope this article helped you better understand the concepts behind Jamstack and why you might consider applying it in your future (and current) web development projects.
