The JAMstack has seen a fantastic rate of acceptance over the past few months, and myriad tools and services can now be used to create fast and dynamic web applications. The JAMstack advocates atomic deploys, which yields more frequent, easier deploy cycles, meaning the latest updates are delivered to users in a simple way.
In this article, we'll review why you should care about this new stack and how to best use it to build faster, more secure websites. You can also watch the talk I gave on this topic at Front Conference in Zurich below.
Tamas Piros - Unleash the Power of the JAM Stack from Front Conference Zurich on Vimeo.
What is the JAMstack?
A better, albeit longer, description of the JAMstack is that it allows us to create performant websites using easily accessible services and deploy them faster, without the need for an origin server.
The last part of the description is curious. How come there's no origin server?
An origin server is a server that has an application running on it—typically a web server such as Apache or Express—that is capable of accepting requests and providing a response.
The key takeaway from this is that when you think about a classic setup like the LAMP stack, generating a page happens at request time: a user clicks on a link, a PHP file gets loaded, that file may make a request to a database by way of an SQL query, it gathers data and returns some template which is then rendered as HTML, and that's what the user sees as the end product. This process happens whenever the same page gets loaded, although there are some caching mechanisms available, which means that querying for the data may not need to happen every time. However, the concept is still there: we have server-side code to execute on each request.
"In other words, we pre-render the markup, so that when a user requests a page, there's no need to do server-side code execution at all."
With the JAMstack, our approach is slightly different. What if we generate the HTML files based on templating logic and structure, ahead of time—at build-time? In other words, we pre-render the markup, so that when a user requests a page, there's no need to do server-side code execution at all. The resulting HTML code can be placed to any hosting provider's server, to GitHub Pages, or even just to Amazon's S3, and be served immediately.
The Complete Guide to Web Design Project Management
Read our complete guide to web design project management for developers, designers, and marketers. Learn how to work with stakeholders, manage budgets, and keep your clients happy.Learn more
Pre-rendering with static site generators
"How we pre-render the markup is agnostic to what programming language we use for the tool doing the job."
This leads me to the second letter in the JAM—APIs.
You might also like: An Insider's Look at the Technology That Powers Shopify.
You’ve probably heard the expression "standing on the shoulders of giants" before. I find this quote to be very relevant here. Let me give you two examples.
Another example is authentication. Authentication is typically hard: we need to store the username/password combinations in a database, make sure it's secured, generate cookies and tokens, validate them, and so on. But what happens when the database load triples? What if we never had a separate auth database? How do we scale these separately?
Today, there are a lot of services out there that help us create contact forms and authentication more easily. Formspree is one example for contact forms. All we need is to add an
action attribute to our form that points to
https://email@example.com, and that's it.