JAM - an abbreviation that allows many puns. But what is behind it?
What is it?
The term JAMStack was coined by Mathias Biilmann from Netlify, today it is quite common for a certain concept in frontend development. But there is more behind the letters of JAMStack than the description of the individual components.
It has already been hinted at with the APIs: A JAMStack application does not have a central, large server on which the entire backend runs and on which the architecture of the frontend is also dependent. Rather, it uses many independent but self-contained APIs. Some of these are commercial APIs that offer services such as user management, payment processing or even weather data. Other APIs are so-called serverless functions; API endpoints that perform exactly one function. This specialization results in very small, easily maintainable modules that are often paid per execution and are therefore usually cheaper than running everything in a large server application.
The code is versioned and managed in a central location, usually with Git, and built from there. The central element of the JAMStack is the prior rendering of the markup during the build. The ready built files are usually deployed to a Content Distribution Network (CDN). Due to the worldwide distribution to different servers and the pages pre-rendered during the build, the performance improves significantly. In particular, the key figure "time to interactive", i.e. the time until the user can interact with the page, decreases. This can not only influence the extent to which the user stays on the page, but also affects the search engine ranking.
The most important benefit: pages load noticeably faster (see examples here). By delivering small, pre-rendered files directly from the CDN, the page can be displayed very quickly by the client while dynamic data is reloaded at the same time. Most of the rendering overhead is shifted to the build time.
With its diverse tool support, websites can be built in minutes with the JAMStack.
With the help of so-called static site generators such as Jekill or Gatsby, the development effort for many scenarios with ready-made components and already integrated API services decreases immensely. In addition, there are frameworks for various front-end technologies that can now also generate static pages (e.g. Next.js for React or Nuxt.js for Vue). Many of the hosting providers also allow direct integration with various technologies, with which a page can be created and deployed within a few minutes.
If custom APIs are still needed, they are quickly implemented using Serverless Functions, independent of other components of the application and thus easy to further develop or replace.
Some platforms integrate a content management system (CMS) for easy updating of page content without knowledge of the technology. These are also headless, i.e. without their own server in the background, but only a frontend for the underlying version management.
By not having one or more monoliths on the backend and splitting it into different, modular and independent APIs, the whole application becomes much more scalable.
External APIs should normally be developed by the provider in a way that is already scalable. Internal APIs as serverless functions can usually be scaled automatically.
Because the main effort in the frontend comes from the build (or client), performance in the JAMStack is much less dependent on the number of calls than in other types of frontend development. At the same time, any load peaks that may occur can be absorbed well by using CDNs.
The same reasons that make sites built with the JAMStack scale very well often ensure lower expenses. Since most components are billed on demand, there is no longer a need to pay for infrastructure for individual load spikes. In most cases where load spikes previously drove the cost of the overall infrastructure, the cost can be significantly reduced. These are advantages that cloud migrations have in general, but with the use of the JAMStack they become even more obvious.
What platforms are there?
A wide variety of platforms offer services that can be used in conjunction with the JAMStack. Some of these have been developed specifically for this purpose, while others are general web services.
In principle, any hoster for static pages will do for hosting the files. However, there are specialized offers that are tailored to the JAMStack. These often offer Git integration with automatic builds and deployments on commits, ready-made CMS options or simple integration of databases.
The most prominent representative for a pure JAMStack hoster is Netlify. Founded by Mathias Biilmann, who named the JAMStack, they are pioneers and the largest company specializing in the stack. There are integrations to various version control systems (Github, Gitlab, Bitbucket) and Serverless Functions, a headless CMS, Analytics and Forms, an API that processes HTML forms directly. The specialization on the stack makes it easy to start a new project quickly.
Many other hosters offer similar services to Netlify. Github and Gitlab Pages are also JAMStack hosters. Below, we review the three major cloud platforms for their JAMStack viability.
The Big Three
Google and Amazon each have their own platforms, Firebase and Amplify, that specialize in rapid web development. Both host static pages and serverless functions, provide authentication, storage, and analytics. Compared to Netlify, there is no practical integration of a headless CMS, but there are numerous standalone ones as replacements. As an advantage over Netlify, both platforms have managed databases with easy API access.
Amazon provides easy access to machine learning services, for example in the form of text recognition integration or voice command recognition.
Unlike AWS, Google does not offer direct Git integration in Firebase, but only in the higher-level Google Cloud Services. Integration can still be set up, though the integration effort is a bit higher.
With Microsoft Azure, there is no specific JAMStack offering. On the basis, however, it offers most of the same features as the other two providers, machine learning APIs, serverless functions, authentication, etc. What is missing is a database API, which needs to be addressed with a backend or in a Function. For this reason, Azure is best suited for projects with very little or very individual database access.
► Interested in architecture considerations for the JAMStack and use cases? Click here to part 2 of the blog article