by David Broadlick on August 27th, 2020
The term JAMStack is meant to define a technology stack that relies heavily on JavaScript, APIs, and Markup. It also is meant to mean a whole lot more than that. In this article, we will explore how this concept is being expressed on the web.
JavaScript
APIs
Markup
Stack
You may be thinking to yourself, JavaScript, microservices exposed via APIs, and of course markup make up most websites these days. How is JAMStack not just describing the web in 2020? When you google "JAMStack" you may see an ad for a portable electric apm, but you will also see a result for JAMStack.org. JAMStack.org is a nice resource that the folks over at Netlify have created in order to help codify a set of standards around an emerging trend in how websites can be built. Let's begin with the first definition listed on JAMStack.org
“ Fast and secure sites and apps delivered by pre-rendering files and serving them directly from a CDN, removing the requirement to manage or run web servers.
This statement does not do a great job of picking apart the JAM in JAMStack but does do a good job of leading with some value propositions, techniques, and specific technologies that are hallmarks of JAMStack. Let's pick this apart 2005 style with a tag cloud.
I have given what I believe to be the proper weight to each of these key words that help make up JAMStack, but before we dig into them, let's start from the beginning of sorts. Here is an exmaple of a JAMStack site.
This site simply takes the last 5 movie picks from the NYTimes Movies API, renders them and adds an ability to vote on which films seem interesting and uninteresting via the Formcake API. You could build this project in any number of stacks, but what makes this a JAMStack site? You can follow along in more detail using the public repo. Below we will go into some of these key aspects around JAMStack in more detail.
One of the most important and talked about aspects of JAMStack is that projects are depoyed as static builds. It is a bit of a debate within the community on whether something must be statically built and hosted to be JAMStack but most JAMStack specific tooling is built around the idea of static builds. For those who are unfamiliar with this term, a static build simply means that a site or app is entirely or partially generated as flat files for serving. Those flat files are then returned to the user upon request as opposed to a server rendering them. The project could also be decribed as "Pre-rendered" since some or all of the site has been build ahead of time. When a change occurs to the content of a JAMStack site, you must rebuild it and serve the new flat files. A slice of a review website's static file structure may look like the following.
Url | Static File |
---|---|
/ | index.html |
/movies | /movies/index.html |
/movies/reviews | /movies/reviews/index.html |
/movies/reviews/tenet | /movies/reviews/tenet/index.html |
index.html
movies/
index.html
reviews/
index.html
tenet/
index.html
The sample movie interest project utilizes pre-rendering with the help of Eleventy. Eleventy is a fantastic way to get started with static sites because it is extremely flexible and can grow with your project.
Like the term serverless, this is a bit of a misnomer. Of course JAMStack sites are served by a server. The preferred server stack however is one that is specifically designed to only deliver static files like AWS S3. There are many benefits to be gained from taking this approach. One of those is stability. When you choose a system like S3 to host your website, you are making many concessions. You have no control over the operating system, the software installed on the server, or even the choice of http server technology. The benefit however is that none of those are of any concern when you are doing something as simple as serving a static file. All of those decisions and layers of complexity are manged and run at enourmous levels at scale by AWS. This makes it very unlikely that your site will go down because those layers of complexity can be highly optimized when used for one purpose. The sample project does not use a custom server because it is hosted on Netlify. Netlify is designed around hosting static files and therefore is highly optimized for this purpose.
The next layer of hosting for a JAMStack site is the use of a CDN. A CDN, or content delivery network, is a way of storing snapshots of the pages of your website and distributing those around the world. When a user requests a page your CDN will deliver a cache or vesion of that page instead of your main server. The main benefit of a CDN is that it is the fastest way to deliver content and the most secure way as well. CDN's can obscure your main server from the world and help protect it from malicious traffic or activity. The sample project utilizes a CDN because it is hosted on Netlify and Netlify uses a CDN to deliver deployed content.
You may think that most websites are run via APIs these days and so why point this out. For JAMStack the importance on APIs centers around the fact that by default a JAMStack project does not have a web server to ping for data since a static hosting server is the only implied server in the stack. Many sites and most apps however need a server of some kind to create interactivity and store / access data. In the JAMStack world, it is encouraged that you either find a service with an API that performs an aspect that a server would or create a microservice using lambdas to still be as "serverless" as possible. Hosting platforms like Netlify and Vercel both support server like features using lambda functions. In the example application, I kept it simple and used Formcake's API to handle all server side features.
Formcake allows a form submission through an ajax request and so it was easy to utilize this functionality to allow users to vote on movie picks.
axios.post('https://api.formcake.com/api/form/4e656bac-5c16-4d5d-be65-eb2928be0179/submission', {
vote,
movieTitle
});
I could have gone to the trouble of creating a lambda based micro service for the voting mechanic but for simple projects it is far easier to use something off the shelf. This is also part of the JAMStack ethos in a way. It's all about what is possible when you fully decouple the front and backend.
JAMStack.org mentions that JAMStack can be used for both websites and web applications. I agree with this sentiment but I also think that JAMStack is not perfectly suited for many types of applications. If you were to signup for Formcake's free plan you would notice that most pages load like a server side rendered application. If you go to your /forms page, you will instantly be greeted with your forms. The same is true for an individual form detail page and your account page. This is because we utilize server side rendering technology in order to deliver our site. We feel this to be a requirement for a SaaS application in 2020 because we are beyond the days of having loading wheels for every component on a single page application. It is a bit of an argument in the JAMStack community on whether an SSR application is a JAMStack project. I don't necessarily care because we should all be choosing the best technology for our projects but I feel that it is worth pointing out. This distinction makes JAMStack better suited for static content or sites with light interactivity in my opinion.
I hope this explanation of JAMStack is helpful to those looking to explore it. It has never been easier to create a powerful website with the pricipals behind JAMStack thanks to hosting platforms like Netlify and tools like Formcake. As always, if you feel that your project could benefit from JAMStack but does not quite meet the requirements, simply take from JAMStack what improves the project and leave behind what detracts from it. This is how we built Formcake and we are very pleased with the results.