The development of websites with the JAMStack approach has been gaining popularity in recent years. The term JAMStack was coined by Mathias Biilmann, CEO of Netlify.
The basic idea of JAMStack is to render web pages in advance and make them statically available. This approach is in contrast to many popular web stacks, where a web server renders and serves pages dynamically, at the time of the request.
Because a JAMStack site is delivered statically, it can theoretically be hosted by any static hosting provider and does not require a complex architecture. The cost, complexity and risks associated with building and maintaining the infrastructure should be reduced in this way.
Dynamic server-side rendering
With each request, the web server usually communicates with other servers or services (data sources). These can be databases or specialized external APIs.
This approach, dynamic server-side rendering, is versatile and widely used. Architectures that make use of the dynamic server-side rendering usually offer a high level of usability, reliability, and community support. However, the approach also has drawbacks:
Disadvantages of dynamic server-side rendering
- Speed: For each request, the entire process must be run over and over again (if no caching is performed). This involves a certain amount of processing time.
- Complexity and maintenance: The code and infrastructure for processing the request and for communication with other systems must be implemented and maintained.
- Availability: The availability of all systems involved must be ensured and monitored. Should for example the database fail, there is no guarantee that a request will be processed correctly.
Pre-rendered, static web pages: the JAMStack approach
The JAMStack approach is to render all relevant pages and content in advance, i.e. before a request to a page is made by the client/browser. When a client requests content, it is already available for retrival.
The pre-processing of the content itself is handled by so-called static site generators (SSGs).
Static Site Generators
A static site generator is a special script that can be executed manually or automatically. It generates pages and content from predefined page templates, local data and external data sources. The resulting static website can then in principle be deployed on any static hosting service. However, for optimal performance, availability, and reliability, it is suggested to deploy the site on a Content Delivery Network (CDN).
SSGs are now available for all major programming languages and template languages.
Automated builds and deployments.
JAMStack hosting providers such as Netlify offer the possibility to automate the build and deployment process. All necessary information is versioned and managed centrally in a Git repository. If needed, other relevant data can be managed in a headless CMS or other external data sources.
Whenever the page templates or data change, the build and deployment process is triggered: the SSG runs, pulls relevant data via APIs from local and remote data sources, and generates the final pages and assets. The updated website is then automatically deployed on the CDN.
In addition to Netlify, numerous other vendors now offer solutions for building and deploying JAMStack websites, including Amazon Webservices, Google Cloud Platform and Cloudflare.
The advantages of JAMStack
Speed: Pages do not have to be generated on a server at the time of the request, but are pre-generated and ready for delivery. This allows for a very high performance and access speed.
Security: Requests do not go through a web server or database, which significantly reduces the attack surface. Pages and content are instead provided as pre-generated read-only files.
Availability: Should data sources or APIs become unavailable, the website will continue to be served by the CDN.
Maintainability and portability: the work was done during the build, so the generated website is now stable and can be hosted without servers that may need to be patched, updated and maintained.
Scalability: Traditional architectures handle high load by adding logic to cache frequently accessed views and resources. In the JAMStack approach, web pages are delivered entirely through a CDN. This eliminates the need for complex logic or workflows to determine which assets can be cached and when. This makes the JAMStack approach very easily scalable.
Disadvantages and limitations
For more complex sites, it is often desirable or necessary to include content that cannot be pre-rendered. Examples include individualized or quickly changing price information, or page sections that require login and authentication logic.
While classic architectures are inherently designed to render dynamic content on the server side, the JAMStack approach requires a replacement. One solution are Functions as a Service (FaaS), also known as serverless functions. These are provided by numerous specialized external providers. The integration of these solutions leads to greater flexibility and scalability, but also brings with it greater complexity and costs.
Modern, hybrid static site generators as a compromise
Those who want to avoid going serverless, but don’t want to give up the benefits of static site generators and decoupled frontends, can turn to modern SSG web server hybrids such as Next.js and Nuxt.js. These frontend frameworks generate and bundle static content as much as possible with an SSG, but also provide the ability to access external data sources via APIs at the time of request using an included web server. However, this is a step away from the JAMStack philosophy, as a dedicated web server has to be operated.
Which sites are best suited for being built on the JAMStack?
A landing page, a static portfolio or even a blog are particularly well suited for an implementation with JAMStack. Pages can be generated using SSGs, which are then delivered via a CDN. Content can be maintained locally in a supported format, for example in markdown format. If required, a headless CMS can be integrated to make content maintenance particularly easy for less technically experienced users.
Overall however, for a webshop, a classic architecture or a decoupled frontend in conjunction with a headless CMS should in many cases be the better choice.
For websites with very fast or in many places changing content, such as trading platforms or social platforms, JAMStack is rather less suitable. Re-generating and republishing the page with constant changes should take too much time to ensure an interactive experience for users. While serverless functions can be used to handle dynamic parts of the page, this adds significantly to the sites complexity. A classic architecture or a decoupled dynamic frontend together with a headless CMS are the better choice in this case.
We support you
Do you have questions about JAMStack or would you like to benefit from this approach yourself? Contact us. We will be happy to advise you and plan your next project with you.