05 August 2021

3981 views

3 0

Getting started with Jamstack

Jamstack is not a toolset; it’s a development methodology that can improve performance, productivity, and flexibility while keeping maintenance simple. Julio Sampaio explains what it is and why you might want to use it.

Jamstack is the buzzword of the moment. If you have ever created a static web page before, you already use it. But what is it?

Jamstack stands for JavaScript, APIs, and Markup. In summary, it is an architecture designed to make the web faster, secure, and scalable via some core principles such as pre-rendering and decoupling, which this article explores.

To make things more realistic with some examples, consider any React application compiled from Webpack that generates static files to be served via an S3 bucket. This is an excellent example of a Jamstack app.

Some people frequently confuse the term with serverless architecture design, which is different. It is often that Jamstack applications can be (and are) hosted in serverless cloud solutions. However, not all the Jamstack uses (such as having your frontend consuming data from a non-serverless .NET API, for example) deal with serverless solutions.

Dissecting the Jamstack

To better understand the term and how it’s composed, there are three main components: JavaScript, APIs, and Markup. Although the article explores these three pieces of Jamstack in more detail, it’s important to note that there’s no strict policy around what tools, patterns, or frameworks you should use to be Jamstack-compliant.

JavaScript

You know JavaScript very well. There’s no discussion about whether you should use JavaScript as part of a web application, but what set of tools you’ll pick to achieve the best result given the app requirements (unless you’re working with an HTML/CSS-only website, of course).

This is where popular frameworks such as React, Angular, and Vue come into play to provide a better way to manipulate the HTML, stylize it with CSS, and enrich it with data flowing from a backend-hosted API.

The static files, as we often call them (CSS, JavaScript, images, etc.), are usually served via a CDN (Content Delivery Network), which also helps with pre-rendering your website contents.

APIs

The number of solutions for various ends in fields such as searching, payments, social media, statistics, and authentication continues to increase, so it’s more and more necessary to have your web apps consume data from many providers at a time. Sometimes they must connect even from the frontend via JavaScript, especially considering the many microservices your company may host.

Regardless of the specific number of calls being made by your frontend pages, or whether your architecture uses auxiliary structures such as API Gateways, proxies, or the notorious BFFs (backend for frontend), you more than certainly will need to interact with APIs.

Jamstack enables clean decoupling of these API services to achieve portability and flexibility as well as keeping things organized and safe, whether you’re calling them from the build or directly from the browser.

Markup

This part causes confusion because it primarily focuses on serving static HTML content to the browser, even though the app is supposed to be dynamic.

A web page built with ASP.NET, for example, wouldn’t be considered Jamstack-compliant because the pages are generated dynamically on the backend. Therefore, the browser needs to wait until the entire content gets loaded.

However, if your app was built with React, which is known for its back-and-forth talk with the backend, but further has its contents generated with tools such as react-static or the famous Gatsby, then your app is probably very Jamstack-compliant.

Take a look at this awesome compilation list of static site generators for fully compliant Jamstack websites, including frameworks such as Next.js, Hexo, and Nuxt, to cite a few. Some of them, like Next.js, pre-generate the HTML contents in the backend so that the browser accesses it with little -to-no loading, making the user experience faster and smoother.

Why should you worry?

Jamstack’s core ideas are not something new. If you go back to the origins of the web, you’ll recap how developers used to create static HTML content manually, page by page, to serve the clients.

The whole cycle from development to deployment was simpler for everyone involved. Obviously, with the complexities required for the systems nowadays, we can not go back to the way it used to be.

However, Jamstack’s not focused on simply serving manually-created static HTML contents to gain in page load speed. It’s goal is on extracting the best out of these experiences to improve performance, productivity, and flexibility while keeping maintenance simpler.

Aside from that, there’s a famous article from AWS known as The 5 Pillars of the AWS Well-Architected Framework, which the company wrote to share with the community their extensive experience in making great architectures. They are:

Operational Excellence
Security
Reliability
Efficiency (in terms of performance)
Optimization (in terms of costs)

When looking at a Jamstack architecture, you can spot each one of these pillars well implemented through:

Reducing the number of internal architectural pieces that move within the systems to decrease the need for Ops people and, therefore, have better operational excellence.
Making sure the app follows the consolidated best practices for security means which increases the overall security.
Providing endless scalability to the various nodes in which your app may be running so that it’s reliable.
Delivering the fastest experience possible due to the static nature of all website resources, including CDN.
Decreasing costs since there are only static resources to host .

The proof that these factors together make sense to the market is the enormous sums of money being injected via investors to companies such as Vercel and Netlify, two of the Jamstack giants of the market.

As expected, Jamstack also attracted criticism from various parts of the community, mainly because of the need to have different chunks of your data spread throughout many services. For example, in a WordPress application, everything’s pretty much in the same place, and you can start up a website in no time. It’s easier to troubleshoot, to audit, to have control over what’s eventually wrong.

On the other hand, having many decoupled pieces within Jamstack allows you to free yourself from repetitive work (such as authentication, payment, etc.) and focus on what’s important.

For example, if you’re creating an e-commerce application, which usually deals with the same set of UI and business flows, why would you spend precious time creating the whole experience for a cart page, its business logic, and its integration with a payment platform? You’ve got plenty of great options to do that for you in just a couple of steps.

Another famous argument against Jamstack is related to the size of your website. When it comes to apps getting started, you’re usually going to have only a few pages that are smooth to convert into static files. However, when the website grows and reaches hundreds or even thousands of pages, this process can become tricky and slow.

What about the speed?

Well implemented Jamstack websites are really fast. Think about it… There’s a lot for a page to process with normal web pages. You need to hit the backend server and wait until it finishes all the synchronous processing. When it’s finished, it’ll send the digested HTML back to the browser, probably filled with some JavaScript code that the browser will also have to handle before it can begin rendering the page to the user.

This whole process is time-consuming. When you’re in the Jamstack world, all the pages are already statically generated and are available to the browser right away. Plus, you also may be using some sort of CDN to host the files, which is great because CDNs deliver content based on the region you’re requesting it, making the whole thing even faster.