JAMstack is a framework-agnostic way of structuring a web application for better performance. It is a modern web development architecture that renders pages before deploying them. It can host an application on static servers or, even better, content delivery networks (CDNs), making them faster than dynamically rendered applications. You can use any user interface (UI) framework, backend technology, database, server, or operating system, and still use JAMstack.
But if it serves pre-rendered pages from a static host, it qualifies as a JAMstack. One of the tenets of JAMstack is that the core site is statically served.
For example, even a single-page app in React that returns a nearly empty skeleton HTML—which is then populated with the content on the client-side with API calls—can be considered a JAMstack application if it is served from a CDN. Why? Because, in order to return the response, it doesn’t have to hit an origin server that has executed logic in real-time. It was a static file served from a static file server.
The following scenarios do not qualify as JAMstack:
If you think about a traditional application, a request from the browser goes through several steps. Even in a simplified model, it passes through a network load balancer that distributes load between two or more web servers, which in turn may make a call to an application server. The application server then calls the database server that executes queries to retrieve the data, passes it back to the app server, and then finally on to the web server.
The web server puts the data and templates together to create an HTML page, which is then returned to the user’s browser. All these steps are executed in a sequence while the user waits for the response.
In a JAMstack application, the compilation of templates with data (i.e., content) to create HTML pages happens much before the user requests a page. In fact, it happens even before deploying the application. The build process creates static HTML pages that are then deployed to a static file server, usually a CDN. These are usually third-party providers who deploy content to geographically distributed servers, specialized in serving static files in a very short time from the server that is closest to the origin of the request.
JAMstack evolved as a solution to a specific problem, i.e., saving page-load time on mobile. It is no coincidence that JAMstack came around 2015, the same period that witnessed a sharp rise in mobile internet usage in the developing countries.
Network latency and speed are factors outside the control of application developers. What they could control were all other delays that added up to the total time it took to display a page. That is how everyone went back to the very basics of what really makes a website. In its very essence, a website is a bunch of HTML files with some styles and images thrown in.
Everything else that was needed to create these static assets was extraneous, which is why the developers figured out a way to disconnect the two processes, i.e., creating these static HTML files and serving those files. They realized that, in many applications, these steps don’t need to happen in real-time and in sequence, which is the genesis of JAMstack.
There are several reasons why some companies are switching to JAMstack. Let’s talk about some advantages of JAMstack in this section.
Serving static files from a low-latency edge server that is geographically close to the user is as fast as it gets. A traditional application that has to execute any kind of logic to render an HTML is going to be slower, even with caching.
JAMstack drastically improves the security of your application by completely disconnecting your dynamic application backend from what happens at the time of request. Everything that is dynamic is executed during the build time before deployment takes place. By the time user is requesting a page, you are just serving a static file. By virtue of its design, all moving parts in a JAMstack application live on a separate infrastructure, which reduces your exposure to cyberattacks.
Scaling, the ability of an application to handle a surge in traffic seamlessly, is not a concern with JAMstack since the content is served from CDNs. CDNs, in recent years, have become very good at doing the specialized task of serving static files quickly under heavy loads. Since they are geographically distributed and have lots of built-in redundancies, they withstand heavy traffic and hardware faults better than the original servers.
In a traditional application, the technical architect estimates the potential loads on each application layer. They also do the costing for adding servers at every layer to handle the load, and then deliberate on the amount of infrastructure that is going to lie under-utilized most of the time. Overall, it can be a nerve-racking exercise.
JAMstack greatly simplifies deployments since it is essentially just transferring files to a static server or CDN. Services, such as Netlify, have provisions for continuous deployment, which means every time a change is pushed to a Git code repository (GitHub, Bitbucket, etc.), it automatically triggers a build that is followed by deployments.
Compare that with traditional deployments where a specific deployable is deployed to multiple application layers in a specific order. There may be database scripts to be deployed to the database, API changes that go to the application server, frontend changes that are sent to the web servers, configuration changes, caches that need to be cleared, servers that need to go through rolling restarts, and more.
Another advantage of JAMstack is that, because it is just a group of static files, the deployments are immutable. You can roll back to any previous version of your site with full confidence that everything will work.
Many content management systems are now making their content available through APIs instead of the CMS being tightly coupled with the platform, as is the case with Joomla or WordPress. These content management systems specialize in managing access for different levels of team access and great content creation experience in general. Your JAMstack application accesses the content through an API, renders the pages during the build, and deploys a plain HTML.
If a website does not require a full-fledged CMS, content creation is still as simple as writing in Markdown. Markdown is a powerful way to write and format content, insert images, videos, etc., and can be learned in a day. It removes the need to create separate stacks for content teams and the marketing team.
JAMstack builds are immutable. When you make a change, the build creates a whole new set of files for the entire site. For a site that has hundreds of thousands of pages, the deployment size can be big. While a new set of files is transferred to the server, and before all older files have been replaced, the site can behave inconsistently for the users who are served a mix of old and new files.
To avoid this complication, many providers (such as Netlify) ensure atomic deployments. The site switches to a new set of files only after the entire set of files has been transferred. Another hassle with immutable builds is that anytime there is any change on the site, the entire site needs to be redeployed. Currently, there is no way to intelligently identify the files that are impacted by the change for deployment purposes.
For sites that publish time-sensitive content, such as news, the ability to swiftly publish a story is paramount. News sites often put out a page with a headline and short description first, and then eventually update the page as more information flows in.
With JAMstack, the build and deployment can run into fifteen minutes or more for larger sites, which can be a serious obstruction.
At GSPANN, we think that using a modern web development architecture like JAMstack is no longer a yes or no decision because almost every application has sections that can benefit from moving to JAMstack. Hence, it is more important to understand whether JAMstack is suitable for your application or not.