Every so often, web development takes a dramatic turn for the better. In this article, we introduce the Jamstack, explaining what it is and why it’s great.
Back in the day, dynamic sites exploded with the LAMP stack. Then the MEAN stack provided a foundation for the next generation of web apps. Now that APIs and reusable components are on the rise, static sites are fashionable again. It’s a “back to basics” of sorts — but not quite.
What Is the Jamstack?
The Jamstack is a redefinition of the modern web for faster and more secure websites. These sites scale better and, with the proper toolset, are a lot easier (and more fun) to develop and maintain.
Let’s break up the term:
- A stands for APIs. You don’t need to program every single functionality yourself, but can rely on third-party processing for a huge number of tasks.
- M stands for Markup. You can reuse components that have already been developed, or create new ones that are a lot easier to maintain.
Isn’t that just buzz?
In a way, yes. The term Jamstack, originally stylized as JAMstack, was coined by the company Netlify as a way of promoting their “all-in-one platform for automating modern web projects.” The principles behind the Jamstack aren’t really new, as web components and APIs have existed for quite some time.
And if, on top of that, you could “encapsulate” all of that process with markup into a reusable component — which you could pretty much drop-in whenever you need that specific functionality — you could potentially save hours of work every time.
Decoupled, Headless, Microservices, Serverless… Sorry, What?
All of these are hot topics in web development, and they’re all closely related but not quite the same. You’ll hear these terms a lot, so let’s clarify some terminology right form the start.
Coupled vs. Decoupled vs. Headless
COUPLED is when the content of a website is created, managed, and stored on the site’s back end, where the database lies (such as the WordPress admin). This content is then pulled from the back end and represented in the browser through a front-end interface (such as a WordPress template). In a way, a “coupled” application is the traditional “full-stack” with the back-end and front-end being different sides of the same app.
In contrast, DECOUPLED is when the back end and the front end are managed separately — meaning that the database and management tools will be on one server, and the front-end somewhere else. Naturally, there needs to be a medium by which both are connected, which is normally an API. What’s more, since the back-end now is effectively separated from the front end, there could be, in fact, several front ends in different locations! (Think of different storefronts using the same engine, such as Shopify.)
In a nutshell, HEADLESS software simply doesn’t have a front-end or a presentation layer. A headless CMS, for example, is one that could generate static content and push it anywhere: a mobile app, an Internet of Things device, a static website. Admittedly, this is also a “decoupled” situation, but here you might not even need an API. Think of a WordPress engine that exported its posts to be served as static HTML files: that’s headless. In fact, you’re on a page that was generated in exactly this way right now.
Monolithic (Tightly Coupled) vs. Microservices (Loosely Coupled)
Put simply, MONOLITHIC could be defined as software that’s built in one piece. Examples might include a mobile app, most applications that you can install on your computer, and web apps such as WordPress. These apps can still have internal “modules” or “components”, but we say these are tightly coupled because they’re an indispensable part of the application, without which the application wouldn’t work.
On the other hand, LOOSELY COUPLED software components work more like plugins that can be removed or replaced, and maybe the functionality will change but the core of the application will still work. This principle enables the “outsource” of functionality through third-party APIs — often called “microservices” — as they provide secondary features (image resizing, login, storing) that aren’t in and of themselves an indispensable part of the application.
Serverless vs. Traditional Computing
Admittedly, “serverless” is something of a misnomer. Whichever computing venture you’re in, there are going to be servers involved. But the way in which you access and manage the severs can be radically different.
In the TRADITIONAL MODEL, you may have an actual physical server (sometimes referred as a bare metal), or a virtual private server where resources are allocated for you — among other users — on a physical server. The resources are limited and, whether you use the 100% of them or not, you’re paying for them as if you do.
In the SERVERLESS MODEL there’s a huge pool of resources offered by many servers all connected between each other. You can just pull what you need when you need it, and scale (up and down) on demand. You can’t really pinpoint any physical server as yours — all you know is that the resources are there regardless of where they come from.
|Physical servers with limited resources
|A pool of unlimited resources
|Prone to malfunctions (i.e. hard disk failure)
|More reliable architecture*
|Pay for all, including idle services
|Pay for what you use (pay as–you–go)
|Need to learn implementation
*Notice that hard disks, CPUs and memory chip failures will still happen. But since resources are assigned transparently, you won’t even notice when hardware breaks and gets replaced.
Practical Examples of the Jamstack
That was a lot to take in, especially if you’re new to these ideas. So, let’s take a theory break and see some practical real-life Jamstack uses.
Case Study 1: Turning WordPress into a static site for a 10x gain in speed
If static is the way to go, then what better than taking a dynamic WordPress (WP) blog and making it into a static one? By doing so, we’ll reduce page load speed and latency by at least one factor, highly enhance security, and improve our SEO while at it.
The process, in a nutshell
- Use a static site generator (SSG) to create posts and pages out of WP but in static format (text, Markdown, HTML).
- Synchronize the static content with a repository on GitHub, GitLab or Bitbucket.
- Automate a deployment pipeline so that every time there’s a change in the repository, changes go live instantly to a global CDN.
- Relax and enjoy free hosting for secure and fast websites with automated deployments. 😎
But what about…
Of course, this generates a lot of questions:
- What about the admin?
- What about the categories and the RSS feed?
- How do I manage content now?
- How about the comments sections, and the newsletter?
At this point, you could kiss WP Admin goodbye, as from now on you’ll be generating content with a SSG. In fact, SSGs such as Jekyll are specifically designed for building blogs, and SSGs like Gatsby.js already come with all batteries included.
Managing content (such as modifying existing posts) is where a headless CMS comes to the rescue. For comments and newsletters, aren’t you already using an external API for those, such as Disqus and Mailchimp?
How do you actually do it?
We can’t cover the ins and outs of SSGs and headless CMSs here, but stay tuned for a future instalment of this series. We’ll present a step-by-step guide to migrating a WordPress site.
Case Study 2: Hosting static sites for free with an automated pipeline
“Free” is something you’ll hear a lot in the Jamstack community — and thankfully, it’s not free as in you still have to tell us your credit card number free.
The process, in a nutshell
In this case, we’ll take our static site (for example, the blog we migrated in Case Study 1) and put it online:
At that point, every change on the repository will automatically trigger a new deployment (via webhooks), which could very elegantly be rolled back, should a problem occur.
Why do companies do this for free?
The overhead of dropping HTML files onto an already-deployed CDN is minimal. Remember, there’s no actual computing involved, no PHP rendering. Unless you host a massively popular site that eats up a lot of bandwidth, companies don’t mind giving out some hosting. And doing so can be good publicity for them.
By giving away lots of freebies, companies also lock you in. By the time you need a premium service (and if your business grows, you will), you’re already with them. That’s only fair — and besides, at that point you were already going to need to either develop an ad-hoc solution to your problem or pay for a service anyway.
How do you actually do it?
Both cases, Netlify or GitHub/GitLab, are very straightforward and require minimal effort. (Nevertheless, we’ll cover the process in detail in a coming article.)
How the Jamstack Compares to Full-stack Development
|Web servers running sites
|Global deployments to CDNs
|FTP/SSH uploads, server restarts
|Pages rendered at runtime
|Pages pre-rendered for speed
|Monolithic apps (e.g. WordPress)
|APIs and microservices (front/back end decoupled)
|Full-stack (front- and back-end languages)
What Else Can You Do with the Jamstack?
Hopefully at this point you understand the benefits of making your site. But perhaps you’re still skeptical about how to do the most basic things without back-end processing, such as user login and managing or storing dynamic content without a relational database (RDBMS).
Here are a few more examples of things you can do with the Jamstack:
- implementing a serverless database with a static site
- identity as a service (IDaaS): stateless authentication
- headless content management systems
- using serverless functions in static sites
- management of multi-purpose forms
- handle multi-platform notifications
- headless shopping carts
- reactive search
It’s inevitable that things evolve, especially in IT. Before it was the LAMP stack and then it was the MEAN stack. Now it’s the Jamstack, and in five to ten years it’s going to be something else. It’s best to embrace these changes and make them ours!
Learning new ways of doing things can sound like a hassle, but it can also reinvigorate your excitement for development. You may discover you spend less time maintaining servers and worrying about security issues. You may find that development takes less effort, and your clients are happier. And you may even become more competitive (and able to ask for a raise) as result. 😀
Keep an eye out for more articles on this topic. While we’ve covered Jamstack over the years, it has become a discipline and practice of its own. We’ll bring you the tutorials you need to become a Jamstack pro, and update our index here on this page. You can also stay up-to-date with our RSS feed or on social media.
- Introduction to the Jamstack: Build Secure, High-Performance Sites
- Jamstack Tools, APIs & Services: A Comprehensive Comparison
- How to Host Static Sites for Free with an Automated Pipeline
- How to Migrate from WordPress to a Static Site Generator
And a whole lot more in the works.
FAQs About Jamstack
In traditional web development, the server is responsible for generating HTML dynamically on each request. Jamstack, on the other hand, pre-builds pages during the build process, serving static assets directly to the client and leveraging APIs for dynamic functionalities.
The key principles of Jamstack include pre-rendering, API-centric development, and the use of a global content delivery network (CDN). Pre-rendering involves generating static HTML during the build phase, and APIs handle dynamic functionalities.
Jamstack offers benefits such as improved performance due to static site generation, enhanced security by reducing the server’s attack surface, and simplified scalability with the help of CDNs. Additionally, it often results in a better developer experience.
Yes, Jamstack applications can utilize server-side functionalities through serverless functions or APIs. Serverless functions allow you to execute server-side code in response to events, providing dynamic functionality while maintaining the benefits of static site delivery.
Jamstack is suitable for a wide range of websites, from simple blogs and marketing sites to complex web applications. However, its suitability depends on the project’s requirements and the need for real-time server-side processing.