With the emergence of Node. js, the development of JS stack is more and more accepted by the company. By far the hottest big front end concept is JAMStack

define

JAM is an acronym for Javascript, APIs, and Markup. In layman’s terms, JAMStack is a front-end technology stack that uses SSG (Static Site Generators) technology and is not dependent on Web services.

“A modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup”

— Mathias Biilmann, CEO & Co-founder of Netlify

  • Javascript: Web rendering tools; JAMStack does not restrict which frameworks or libraries are used
  • APIs: A set of abstractions for server-side behavior, interacting primarily with Javascript via HTTPS. It can be a service provided by a third party or a function built by itself
  • Markup: A web site is a static resource hosted on the CDN. Markup is the source file that generates these resources. Markdown was considered a Markup language when Markup was first introduced, but these days Vue or JSX files are more commonly used

architecture

OK, just to list the definition of JAM, let’s take a look at how it compares to traditional web architecture:

Compared to traditional dynamic websites

Traditional vs. JAMStack

It’s intuitive to look at the architecture diagram. A traditional Web architecture would have a heavy back-end server; JAMStack is closer to a purely static site — it even hosts data and HTML on a CDN via SSG.

Why is JAMStack such a strange architecture? Again, we have to look at the application scenario and the problem it’s trying to solve. For some news, enterprise official website, small e-commerce, such as Content Management System (CMS) website, its Content update is very slow. Traditional web architecture requires a real-time online service in any case, which is a weak point in dealing with this immutable content: it requires a small amount of computing, but it still requires a large number of back-end and operations staff to maintain the site’s security, stability, scalability…

JAMStack provides a new solution in these scenarios: distribute static pages and data directly using CDN; These CMS become a pure static site, the above operation and maintenance problems are naturally avoided. The Trump administration is said to have saved US taxpayers $3 million a year by changing the CMS on the White House website from Drupal (PHP architecture) to WordPress (JAMStack architecture).

Compared to a purely static site

Since it is all in CDN, why not use a purely static website? Let’s look again at how JAMStack differs from a purely static website. Pure static sites also distribute all content to the CDN, but they are not very friendly to hosting dynamic content. For example, a company wants to change its static home page announcement; The traditional approach is that operations (not development) manually modify the page and then update the deployment. But this solution seems premodern — editing the page is cumbersome, and you have to navigate a series of manual deployment processes yourself.

JAMStack offers a more dynamic solution: JAMStack actually has a back end — a back-end system called a Headless CMS. The so-called “headless” means that the user’s UI display is decoupled from the background service, and the background system is not responsible for customizing the user’s UI — that is, to “head” — only responsible for data management. It goes like this:

  1. Operations personnel enter data in headless CMS systems
  2. The headless CMS writes data to the DB and triggers the SSG deployment process
  3. SSG pulls git code and DB data and generates static resources
  4. The SSG then deploys static resources to the CDN and cleans up related caches

Headless CMS

Of course, the actual project will most likely operate on the Admin page and then call the API of the headless CMS. JAMStack’s entire operating platform is provided by a service provider, and the pages are more user-friendly and automated, reducing the possibility of errors by non-technical people.

Premium JAMStack

The JAMStack mentioned above was the theoretical model when the concept was proposed five or six years ago, but I’ve looked at some sites that claim to have JAMStack in place, and their implementations aren’t that dogmatic:

Advanced JAMStack

JAMStack still sends API request data from the client, but API servers are lightweight, usually serverless methods like Lambda. Some CMS websites also integrate Auth service, search service, payment service and so on, but it is usually the JS library of the three parties directly integrated in the front end.

The advantages and disadvantages

OK, we have a brief introduction to the architecture of JAMStack, just to review it a little bit. JAMStack has the following advantages:

  • High performance: Almost purely static web pages, network requests basically flow to the CDN, with few additional data requests
  • High security: Don’t worry too much about server and database security
  • Low cost: Static resource hosting is very cheap
  • Better development experience: The front-end is developed separately, deployed separately, and tested separately, fully decoupled from the back-end architecture

Of course, the disadvantages of JAMStack are also obvious. The business scenario is very small and can only be used for CMS sites with infrequent content updates. There are also commercial practices of Headless Commerce in foreign countries, but the prospect is not clear.

Tools & Best Practices

The toolchain of JAMStack is basically the same as the front-end of traditional Web app, but the difference lies in the choice of SSG scheme: generally speaking, it is the choice of SSR framework of the three front-end components (React, Angular, Vue) — Next, Scully, Nuxt, etc. But I’ve recently found some full-stack solutions for JAMStack:

  • Redwood.js: React + GraphQL + Prisma serverless framework
  • Blitz. js: Typescript + Next + Prisma + Auth’s Node framework, right out of the box
  • React/Vue + Egg/Midway + Typeorm Serverless OOP framework

These solutions are essentially Full stack Monorepo templates for Node, out of the box, and highly adaptable to mainstream Serverless services. However, the real use of a generated environment may have to wait.

In addition, JAMStack has developed a set of best practices over the years, including:

  • Atomic Deployment: Each deployment should be a complete site snapshot with no dirty pages
  • Cache: Once static resources are updated, the CDN Cache should be immediately clear to ensure that the online site resources are unique
  • Git: Build workflows strongly rely on Git hooks. Markup changes should be quickly responded to and easily tracked
  • DevOps: Can quickly build and deploy a new environment based on different development stages and operation and maintenance requirements, facilitating development, testing, acceptance…

summary

Technically, JAMStack is essentially an enhanced static website, not much of an innovation but a derivative of serverless. However, the “front-end apI-back-end DB” technology chain of traditional Web development is too cumbersome, and JAMStack is an improvement direction, at least in some scenarios.