Let's take a look at the Jamstack, the architectural approach that makes your websites faster, safer, cheaper, and all that with a better developer experience.
What Is It?
The Jamstack is an architectural approach and the letters "J A M" are an acronym which actually stand for:
- JavaScript
- APIs
- Markup
JavaScript
JavaScript is the universal runtime of the web. Every browser can handle JavaScript and it's the language that brings interactivity to every modern-day browser. JavaScript can either be written directly or act as a compile target.
APIs
More and more APIs are created every day. Take Stripe for example. They offer an API to process payments for you. It is designed to be integrated into other projects and doesn't offer a fully-fledged frontend like Paypal does, for example. Everyone can integrate an API or multiple into their project and make use of what they offer.
Markup
The web is made up of markup. HTML is the markup language of the web. Every website contains HTML that can be rendered by a client's browser. Without HTML there wouldn't be websites.
Core Principles
Next to its basic building blocks, the Jamstack embraces a few core principles, some of which are:
- pre-rendering
- decoupling
- (Nearly) everything lives inside git
Pre-Rendering
Traditional approaches work as follows (approx.):
Your browser sends a request to a server. The server fetches data from multiple data sources and starts rendering HTML from a template while filling in the previously fetched data. It then sends back an HTML document that your browser begins parsing. If it encounters additional resources like stylesheets, JavaScript, and images, it sends more requests to the server and fetches that data, as well. When everything is fetched (at the latest) your browser can finally render the full page. This doesn't take into account that some resources can be fetched asynchronously while the rendering already takes place, though.
The Jamstack optimizes this process by moving some time-intensive tasks from the run time to the build time. Instead of fetching data each and every time a user sends a request (not taking into account client- and server-side caching), the data is fetched once, at build time. It is then rendered into a static HTML page that, once deployed, can be served to each and every user requesting it.
Decoupling
Traditional approaches have tightly coupled stacks. To actually be able to create HTML at runtime, you need business logic and logic which accesses the database. This creates a relatively tight coupling. This approach also played a part in the creation of the full-stack developer. A developer that can build such an application and write frontend, as well as backend logic. Full-stack projects can only be deployed as a whole. You can't update the frontend without updating the backend, too.
When built with the Jamstack, a project focuses on the frontend. It is a fully separate application that accesses already existing APIs and data sources. It puts the focus on the frontend work while optimizing the outcome heavily. And what's served later is served as fast as possible. A benefit for users and search engines. Both value speed pretty high these days. The application can be deployed separately from everything else.
(Nearly) everything lives inside git
Git is one of the (if not the) most-used version control management tool(s) in the world. Most source code is already tracked by git and enables atomic deployments from a tag or a commit hash.
Adding your website's data to it simply makes sense. One commit does not only contain the structure and functionality of your website at one certain point in time, anymore, it does now also contain its state and content. A commit then contains the one article you published under this hash, and when you go back one commit, this article is gone again. If you want to revert your page to this exact state, you can simply revert the state of your git repository.
This streamlines the process by a lot. No more reverting git state, then reverting the database, and so on. Git is the only master of truth. A change in your repository triggers a new build. This build, when finished, leads to static files. Those are uploaded to the content delivery network that invalidates its caches and then serves the updated version.
How Does It Work?
You've already read about some of the principles of the Jamstack, but to give you a sum-up of how it works:
Sites are pre-rendered by a static site generator. At build time, data is fetched from multiple sources and rendered directly into static pages. Assets like images and resources like JavaScript are optimized and inserted into the HTML document. The static files are then usually deployed to a content delivery network that keeps your site as close as possible (geographically) to the user while also leveraging caching.
At runtime, additional existing APIs can be used to enrich the overall user-experience. This means that features like commenting on articles, making a payment, or liking a post can still be handled dynamically at runtime, but everything that can be served statically otherwise, is served statically to reap the benefits of increased speed, ease of use, and so on.
Conclusion
The Jamstack is an interesting approach. Its concepts aren't new but due to the rise of the cloud and content delivery networks in recent years, many of them actually became possible on a large scale.
There are many service providers, nowadays, that give you the basic infrastructure building blocks to base your next Jamstack project on. For example Netlify, Vercel, even AWS all offer Jamstack hosting, integration, deployment, and supporting services. These are only some names of larger players in this field.
Frameworks like Next and Gatsby or tools like Hugo streamline the experience for developers and let you use the skills you already have to get building. You don't need to learn a lot about the generators themselves, you can use the skills you already know, which are HTML, CSS, JavaScript, and so on.
So, are you already using the Jamstack? Do you plan to use it? What do you think?
Before You Leave
If you liked this article, feel free to visit me on Twitter. I regularly post content there. It is basically the platform where you will find my content first before it lands on my blog or somewhere else.