The JAMstack rendering process

Everything is based on Headless

A few years ago, the traditional monolithic scheme was the most used way to create a digital platform; a web server, a database, and everything encapsulated in a single server containing all the connections and dependencies.

However, as time went by, web trends changed, people were no longer navigating on a computer, and the volume of users grew to unimaginable levels. This happened because platforms became more robust, seeking to integrate each new aspect, although unfortunately, they were unable to maintain the change as a dynamic.

In this scenario, JAMstack was born, changing the paradigm of how to build web architecture and incorporating the idea of change as the (almost) natural process of any platform. The secret? It removes the head from the body, unleashing the potential of both.

We love that analogy, even though it sounds weird. Still, at its core, it's about decoupling the frontend from the backend and separating everything that has to do with the interface, the content, and its functionalities from the internal systems. So, it optimizes content delivery to any device that requires it right away since it is pre-loaded (pre-rendering) and ready for delivery, enhancing the digital experience.

What is JAMstack's relationship with pre-rendering?

When we talk about pre-rendering, we mean that the entries and content part of your platform are loaded when compiling your site. Meaning that the content displayed by a client is not necessarily loaded when requested but may already be stored in the cache (usually) of a CDN. You may wonder what this is for: you see, in the JAMstack methodology, it is all about optimizing your platform so that it is always ready for any device, anywhere; even if they have a slow connection and are thousands of miles away from the country where the platform resides (operates).

Imagine it this way, you own a small mobile stand of your favorite food, and on a typical day, you know you will sell, let's say, between 30 and 50 plates, which is a good number for your kitchen capabilities. Then you think about taking your stand to the busiest resort in town, and immediately your sales go up to 300 plates. But, your kitchen can't deliver that volume of dishes on the principle of; dish ordered, a dish cooked.

What would you do in a situation like this? Would you continue to use the same tools and the same way of serving? You need to change, or else people will start to leave without buying since nobody wants to wait too long for their food. That is why you start preparing in advance the most frequent side dishes and accompaniments because you know that you will still be preparing that special ingredient that every customer is looking for. Still, all the other ingredients will be ready to serve. It's a culinary revolution; you increase your sales, have operational security, and grow your entire business.

This is the mentality that encourages working with the JAMstack methodology. Rather than using a specific technology, we focus on building static sites that compile in advance (almost) all the content, and when a client makes a query, the result is ready to be delivered without needing to go through a web server.

Learn about deferred rendering in JAMstack: DPR and ISR

You may be wondering how this is possible; well, this is where the previous section makes sense, it's all based on Headless. By working in a decoupled way, you don't need every web request to be processed by your server and queried to your database. Since it is loaded to your CDN’s cache at the time of compiling, you no longer need a server to process it or a database to query it.

This is especially relevant for large brands that have platforms with hundreds of products and thousands of content entries. Imagine how a server would respond if it had to load all that content repeatedly, that's why the solution for them is pre-rendering.

The best thing about building headless architecture is that you are not tied to a single vendor or technology, which has allowed different companies to develop their own rendering recipes. But all of them always focused on optimizing the platforms to give large companies the best technology.

• Incremental Static Regeneration of Next.js (ISR) is a proposal that uses the static site condition, typical of JAMstack, to load new entries without recompiling the entire site. Thus, what is already stored in the cache is maintained while the platform regenerates with new entries from behind.
• Distributed Persistent Rendering of Netlify (DPR) this proposal has an additional approach, and that is to reduce the complexity of the systems (JAMstack philosophy). Therefore, to optimize the loading of the platforms, they distribute the content. When compiling the site, all the basics are loaded in the cache, and if a client asks for something that is not loaded, the platform loads it, and thereafter, it remains in the cache. Do you remember what to prepare the ingredients beforehand?
• Deferred Static Generation of Gatsby.js (DSG) follows the same spirit and is Gatsby's way of deferring the content loading, allowing the site to load only critical content at compile time. And it is often the case that big brands have products that are not in high demand, making it better to leave them waiting to be requested.

At Reign, we work from JAMstack because we share the idea that the most crucial is to optimize the platform's performance, but always with the flexibility and freedom that a headless architecture offers. So, those sites with hundreds of thousands of pages can operate with the same flow that people expect you to have.