DEV Community

loading...

Micro Frontends Patterns#4: JAMstack

okmttdhr
.
Updated on ・4 min read

JAMstack is an architecture that combines JavaScript, APIs, and Markup.

That is not limited to a specific technology, but it has the following architecture (The right one is JAMstack, the left one is a traditional 3-tier architecture, from jamstack.org)

igsa67qnb8r0sed6t24k86jk4yzx

JAMstack's JAM is used in the following contexts;

  • JavaScript - not only to add dynamic functionality to applications, but also as a runtime that encompasses APIs and Markups.
  • APIs - all interactions with the Backend and third parties are done using APIs
  • Markup - HTML that is generated at build time, statically hosted, and delivered via CDN.

The overall system will be a layered architecture that looks something like this;

x4hstra2okscczf4rzxjpkxscbay

For the key concept, take a look at jamstack.org. If you want more details, I recommend the book Modern Web Development on the Jamstack.

Here, I will introduce the specific architecture and some of the important technologies in JAMstack.

Single Page Application

Single Page Application (SPA) is an application that uses JavaScript to dynamically retrieve and update data and perform screen transitions. It eliminates the need to make a round trip to the server side for each screen transition. It is also important in the sense that it is an architecture where the Frontend is starting to be clearly separated from the Backend.

Some SPAs don't do prebuild, so I guess you could argue that they are not strictly speaking JAMstack. However, in Modern Web Development on the Jamstack, it's mentioned as an example of JAMstack, and aloso it's stated that "JAMstack is a movement, a community collection of best practices and workflows that result in high-speed websites that are a pleasure to work on".

In addition, the SSG, which will be discussed later, can be combined with SPA to demonstrate its value, and SPA can be said to be an indispensable part of JAMstack.

Static Site Generators

Static Site Generators (SSG), as the name suggests, are software that generates static markups at build time (prebuild).

The difference between SSG and conventional static sites is that SSG provides flexible markup generation at build time. For example, in SSG, dynamic data can be generated at build time. This eliminates the round trips that occur with monolithic apps and allows you to simply deliver static content via CDN or other means.

bfdvjz6ohwld87mkygoi13z1ufyf

This is also an abstraction of the Backend. It guarantees technical independence between the Frontend and the Backend, and allows Web to be more like a native app.

Incremental Static Regeneration

Next.js has a feature called Incremental Static Regeneration.

In a nutshell, it's a technology that returns cached static content on request, while regenerating the corresponding content behind the scenes. For more details, please see the following.

Use cases include when there is a large amount of static content in an e-commerce site, or when you want to always show the latest content even though it is static.

Incremental Static Regeneration can be a feature that extends the use cases of SSG. It embodies JAMstack's best practices for completing static content at the edge, and provides an option for developers to first ask, "Can we do SSG?".

Progressive Web Apps

Progressive Web Apps (PWAs) are web apps that use new web APIs and features in addition to the traditional web to bring a native app-like experience to web apps.

I think the reason why the description of PWAs is so abstract is because it doesn't refer to any specific technology. There are three elements that make PWA; Capable, Reliable, and Installable, web.dev has more details.

We believe that PWAs are also a part of the JAMstack movement, such as turning the web into apps with the App Shell model, communication with APIs, Offline Capability and Installability.

Pros and Cons

Pros

  • Time to First Byte is fast.
  • Being a static asset, it can easily benefit from a CDN layer. Also, there is less to consider in scaling.
  • Deployment can be separated from the Backend, making loosely coupled development easier.
  • No need to worry about the technical limitations of the Backend, and can freely decide the Frontend stack.
  • Since the Backend is limited to APIs, it is easier to reduce security considerations.

Cons

A simple SPA has the following disadvantages, which are solved by SSG.

  • First Contentful Paint (FCP) tends to be slow.
  • Time To Interactive (TTI) after FCP tends to be slow, causing the user to wait during initial drawing. Also, the size of JavaScript increases as it scales, so performance needs to be considered.
  • Weak on SEO, more things to consider

Summary

JAMstack is a relatively new architecture, but I feel that it is gaining in popularity as a web best practice these days.

The Frontend is no longer limited as it was in Monolith, and we can now take full advantage of Frontend technologies. With the loosely coupled technology, deployment can be done separately, and it will be easier for applications to run improvement cycles.

At the same time, however, it also means that the complexity has shifted to the Frontend, which requires more specialized skills.

Discussion (2)

Collapse
leon0399 profile image
Leonid Meleshin

why does JAMstack is weak on SEO? On the contrary, it provides great results, especially on performance side, comparing to SSR.

Collapse
okmttdhr profile image
okmttdhr Author

You will find "A simple SPA has the following disadvantages, which are solved by SSG" in this article Cons section, which means those disadvantages are for the SPA without SSG, not for JAMstack itself.