Advanced Site Rendering Patterns on the Jamstack

Hello. Thank you very much for the introduction. Of course, my name is Ekene Eze, and today I'll be talking about advanced site rendering patterns in the JAMstack. Well, I'll get to my introduction just in a minute. Yes, so I work as a developer experience engineer at Netlify and I have a YouTube channel where I make video tutorials about web development. If you want to follow me on socials, I'm on Twitter, at Ekene underscore IO. Let's jump into it.

Okay, we're not jumping into it quite yet because I'd like to also tell you that outside being a developer experience engineer and doing my thing on YouTube and learning JavaScript and doing work with it, what I really want to do is be a mixologist so that I can get all my friends drunk for no reason at all. That's probably a story for a different But eventually, I will get to tell the story. And I hope you all are here to hear it when that happens. But I will go on and get started for today.

So what you will learn today is how rendering works on the jumpstack. If you've been building jumpstack applications with Knox or with any other framework, in your static sites generator, you will better understand how rendering works. You will also understand the pros and cons of some of the rendering patterns we have, what they bring to the table and what trade offs they also bring. Finally, you will also learn what to do when your jumpstack site is performing poorly. For instance, if it's taking like too long to build, you'll understand why that is happening and the things you can do to help speed up that process. But before we dive into it, let's take a trip back memory lane to understand why this is even important in the first place.

All right. So before now, what happens is when a user comes to your site and requests for products. And in this case, I mean, what I mean is if a user comes to your website and they click on products, ideally what happens is a request goes off to your server and depending on your server architecture and how it's configured. This request could go through your load balancers, your web servers, your application servers, and databases and all of that thing that goes on behind the scenes to serve that request. So ideally, this goes out, your server processes the request, produces the right contents, and sends it back to the user. While all that is going on behind the scenes, of course your user will be seeing either a blank screen or a loading screen or a spinner, depending on how you build your site. So this is not very good for the developer and not also very good for the user who is using the application because they get to stay at a blank screen or a loading screen for a while before the actual contents get served. But building the JAMstack way kind of like helps us solve that problem, and it solves it this way, right? All of that processing happens before the site goes live. So for instance, if you've built your JAMstack application, once you run the build command, what happens is the static site generator goes off and makes all the requests on your behalf, right? And generates all the pages, generates all the dynamic routes and all the parts that will be available in your application. And then the content is now served to your users. So what happens now is instead of users coming to your site and clicking buttons to make requests, all of those requests happens at build time so that when your users come to the site, all the contents they need are readily available. So there's no lags, there's no waiting time, there's no loading spin-outs going on forever. So this is a good way, but as you can imagine, like every solution, like everywhere that technology comes with a solution, they also have some trade-offs.

But before we talk about the trade-offs, the benefits we get from using the JAMstack way is that your site is faster and your users are happy. I mean, right? If you don't ever have to wait on loading screens to fetch content, or if you're visiting a site and you're seeing that it's fast, if you click a button, everything happens as it should without any lags, your users will be happy. As a user, I would be happy, right? And then you also get better SEO out of the box as the developer or as the owner of the site, all your sites is being, all the content of your site is readily available. So Google and all the search engines will be happy. They can crawl and index your site properly because all the contents is available ahead of time. And also deploying on the CDN means you have limited point of attack. So it's more secure because you only have to worry about your site and the CDN. You don't have to worry about securing your databases, your load balancers, your web servers, and all of those things, you just have to care about your own application and then the CDN does the rest for you. Building this way also enables developers to stay within their core skill sets. I mean, I see myself as a front end developer. I like building with Vue.js and Nox.js. I don't ever want to have to worry about how load balancers or containers or Docker works, right? And building this way kind of like helps me just stay within my skill set and not worry about those things that I'm not comfortable with by default.

Anyway, that's that about building this way. If you feel like these people who are dancing here, that's exactly how I felt when we finished the JAMstack Explorer platform with my team, we built it all on the JAMstack, we did a lot of dynamic things, but at the end of the day, we had fun and we didn't really do so much of the things that makes us uncomfortable as developers.

All right, but like I said, every new solution introduces its own trade-offs. So there's a little bit of a trade-off here, which is that if you build this way, when your site gets large, as you can imagine since the build process kind of generates all those pages for you ahead of time, it means that if you have so many pages in your application, if you have 10,000, 100,000 pages, all of those pages are going to get generated at build time, which means you get to spend a little bit longer waiting for your sites to build as opposed to just deploying it as it is.

And to make that a little bit clearer, imagine that you have a site like this that has a thousand products. Once your build process kicks off, all of those products, all of those products are going to get generated. This is before your site is deployed before it goes live. So the build process takes like, let's watch this 100, 200, 300, 400. It goes all, all the way to 8,000 products gets generated, and then if you have more, if you have like 50,000, for instance, you're going to have to wait for all of that time to expire before your, before all your product pages are generated and deployed.

So take, for instance, that I have a site called my site.com. In that site, I have 1,500 product pages, blog pages, and press releases. Now, what happens is I have a total of 4,000 pages, right? So if I want to deploy this site, my build process is going to kick in and pregenerate all of these pages. And let's just say that hypothetically, this is not ideal in any way, but let's just say for the purposes of this presentation, that it takes our static site generator one second to build one page. Like I said, this is not the reality, but let's work with that. So assuming it takes one second to build one means it's going to take me 4,000 seconds to deploy the sites, to build the site before I deploy it. And that is like an hour plus, right? So imagine building your site, getting ready, finishing, putting out the finishing touches and just want to deploy your site and you have to sit there and wait for its build for one hour. That is not good. Nobody wants that. And that's not even all, right? Like if you want to update the site, you go through the same exact process. In this case, imagine that you want to add one more product page to your existing site, which you have built and deployed. What happens is your product is going to get one more product page, right? So instead of having 1,500, you have 1,501, which gives you 4,001 pages. And what happens is because it's a Jamstack site, the build process is going to start again. And when that happens, it's going to rebuild the entire site all over again. So that's another one hour plus that you have to wait for your site to build, just because you updated one product page. That is not ideal. I don't want that. I'm sure you don't as well, which brings us to the solutions. So while all this is going on, everyone in the community realized that this is a bottleneck that needed to be fixed. So that's one good thing about the Jamstack community, everyone rallies around to find solutions to problems like this that affects everyone. So the first solution is incremental build.

I think this originated from Gatsby some years ago when they were figuring out how to lower build times on the Jamstack. And just to make that very clear, what incremental builds does is, imagine that you have a site that has just seven product pages. When you deploy the site, it's going to be a live site. People can interact with it, but they can only see seven products, because that's what is available on your site. But what happens when you update that site and add another product page to make it eight pages? In this case, your entire site is going to get regenerated. And what that means is, as opposed to building just one page, it's going to build eight pages, because it's going to build even the one that has already been built before, because of course it has to regenerate the entire site. What incremental builds does is, give you an opportunity to build only the new page that you introduced to your site and leave the previous pages as they are. This kind of saves an incredible amount of time when it comes to subsequent builds of your site. In this case, you had seven pages built before, you added one more page, only that new page gets generated, everything else stays as it is. So while updating your site, you don't ever have to wait for all those long times to rebuild your entire site. But of course, it had its trade offs, it doesn't impact the initial build. For instance, if I had like 4000 pages like I had in I had in the other examples, when I deploy that site, I'm still going to wait for that one hour plus time, hypothetical time to wait for that site to build the first time so it doesn't get impacted. It only has an impact on subsequent builds and the site updates. And also it breaks the atomic and immutable deploy concepts, which is something that we are very particular about in the JAMstack. If you don't know what that is, I will put a link in the description in the output a link in the resources section so that you can look it up and see what that is all about.

Alright, and the next solution that came up in the community is microsites. This pattern literally says if you have a big chunk of sites that is together and has a lot of different pages, consider splitting them out into different micro sites so that it's easy to manage as independent variations of your site as opposed to one big bulk that has to build together. To visualize that, consider this globe on screen right now as a big website that has three different sections, has the product, the blog and the press what this pattern is suggesting is why not split this into three different distinct sites so that they are not all buckled up into one big site that has to build together and that are all together.

The advantage of doing things this way is all the parts of your site are independent of each other, which means if I'm building my product site, it doesn't affect my blog and it doesn't affect my press. If I'm updating a blog page, my product site will not rebuild. The press releases site will not rebuild because they are all individual and independent sites who are just like tied back together to my main sites using proxies and redirects.

And how that works is imagine that I have these three sites split out into different deployed into different websites. So I have a products website. I have a blog website, a press website that are all individual, standalone websites. And then I come to my sites.com, which is where I want to bring them all three together. I can use a redirect to point my, my site.com slash products page, to point to that products website that I've built somewhere else. The same will happen for blog and press. And if you don't like redirects or you'd rather use proxies, that is also available to you depending on your preference and how you want to architect your site.

Ah, well, of course it do have some trade offs and some caveats. Uh, like I was saying before, it has complex redirect and proxies. So if you're not very familiar with redirects or how proxies work, this might not be very friendly for you because you really need to understand how to do that. Uh, to build a microsite, it doesn't impact initial builders. It's kind of like just how incremental build work, it doesn't have so much impact on the, on the initial build because if you're deploying your product sites, if you're deploying your blog, if you're deploying your press, it all deploys as independent sites. But if you still have like 5,000 product pages on site, it will still take all that time to build again. Although now smaller because it's one site as opposed to when it's building the three sites together. Of course you have several sites to manage. I mean, uh, in this case I just have three sites, products and blog and press, but imagine that you have like 15 different sites, sections of your site that you're building independently of each other. It means that you have it. It means that you have like so many sites that you have to manage in individually that could be tough sometimes. Uh, which then brings me to the last, uh, to the, uh, ISR solution. This is where things start getting interesting. I would say, right. Incremental static regeneration. That is always a mouthful. why? Uh, it enables you to choose, uh, what kind of pages, uh, how much pages you want to build at build time.

Does that make sense? No, it enables you to choose how many pages you want to generate at build time as opposed to generating everything by default, right? It just says, okay, I have 10,000 pages, but I want to generate only a hundred of those pages when my site is building and I will do the rest when you use us request for them. And how it works is see, this is a typical JAMstack process, right? When you build your site, it generates all the assets and all the pages and all the dynamic routes and everything, right? But I say is, I will give you the opportunity to generate only some part of those pages. You don't have to do everything at a build time. You can generate only the ones that you want your users to see immediately, and then you can do the rest whenever people ask for them, which is cool, right?

Now, this is how it plays out. I know you're already asking, like what happens when a user asks for a page that wasn't pregenerated at build time, right? That's a good question. But what happens is first you need to understand that when your site is generated and deployed, all the contents of the sites gets pushed to the CDN that then serves your users, right? Now, when a page doesn't exist in the CDN and a user requests for them, like in this case, the page that I circled with the red circle thing, what happens is that particular page starts getting regenerated. Well, in this case, it starts getting generated the first time because it wasn't generated before. And while that is going on, ISR will serve a fallback version of that page to your users so that they don't see a loading screen or something like that. And while that's going on, the page is being generated in the background. And when the generation is done, the page gets put into the CDN that then serves your users the actual content. Cool. Cool.

It's... before I talk about the caveats, notice how it has a high impact on the initial build that we've been trying to solve for a while. So because you now have the opportunity to say, oh, I don't want to generate every part of my site at the same time when my site is building, I only want to generate 5% of it. Like, you can literally decide which pages you want to generate at build time. It impacts our initial build a whole lot because as opposed to waiting for 5,000 pages to build, you can build 100 or 500. And that will ensure that your site is deployed a lot faster than before. It also gives us the best of both worlds, right? You can statically generate all your pages, but when you just ask for content that wasn't generated at build time, you can use SSRs to generate those pages and serve them to the users. But of course, it has its tradeoffs as well. Because ISR uses stale while revalidates caching strategy, it means that you run the risk of serving stale contents to your users when the site is revalidating. I also put a link in the resources section if you want to understand stale while revalidates better, I will put it there to explain that very well for you. It also compromises atomic and limited pool deploys because of how it affects content going in and updating a site that has already been deployed without redeploying the sites to purge the cache and all of that. This is also not framework agnostic. I'm a front-end developer and I like building with Vue and Knox. But this is only available to next year's developers, which means it doesn't really help me in any way. Those are a few caveats. Let's see the last solution that I want to talk about today. And that is distributed persistent rendering that is currently in beta, but will probably be out of beta soon.

And that is distributed persistent rendering that is currently in beta, but will probably be out of beta soon. What this does is it removes the need for revalidation and just purges the cache completely when there's a new deploy. So this way, all the content that you've generated is available to your users called critical content, the content that you've deferred will be generated when and only when a user requests for them.

And I think this uses serverless functions to generate those pages on demand and then put them in the cache. When you need to update the cache, you just run a new deploy and it will purge the cache. And this is intentional because this way you preserve atomic and immutable deploys and we are not compromising any of the Jamstack concept that we really care about.

And we've seen this come to life with the new Gatsby v4 release, something called deferred static generation, which is a new rendering mode that was introduced in Gatsby 4. And as you can see, it's out there in the world, people are using it. I think I'm particularly liking it. I'm currently building something with DSG and I'm seeing how we can completely do SSG and SSR on Jamstack sites without compromising any of the core principles that we really care about.

The resources section that I talked about, I'm going to add all the links to the things I talked about so that I will just provide you more resources to kind of like understand some of these things if you don't already know them or if you're not familiar with any of these things.

And thank you all for having me. It's been fun. I've had a good time sharing these things with everyone. Once again, I'm on Twitter and everywhere else on the web at kenny underscore io and that's my YouTube channel on screen if you want to check that out. Thank you all and see you next time.