Cache Priming Magic!

[Music] Hey, [Music] hey, hey. [Music] Hey, hello everyone. How's it going? Welcome. I was still pasting the live stream link to our Slack when the timer ran out. I know. I was trying to post on Discord, but I'm gonna do it now. Do you want to intro us, Tim? Yeah, sure. So, welcome back. It's been a while since we've done a developer pulse live stream because we had content con and a lot of really cool product updates, releases, things like that. And so, first things first, Dean, right now here it's so hot. In my language, we basically say the birds fall out of the trees. That's how hot it is. How is it for you where you are based? Uh, it is pretty hot here. We are looking at uh 87 Fahrenheit. Uh getting up close to 100 though today. Real feel. Oh well. Yeah. So here it's closing in on 100 now because I'm towards the end of my day. So it it builds up anyways. Low for you. I guess it's the same, right? It's the same. It's super hot. It's even hotter. I think we're I think the whole really the whole country of the US but like is under a massive heat dome and heat wave. So, it's pretty bad. We're sitting right around like 92 Fahrenheit right now, but also 96% humidity. Oh, yeah. That's the thing. For us, we're we're sitting at 50, so we're okay. Anyways, with that out of the way, it's important to talk about the weather sometimes. Um, so today we want to talk about our product launch and we have our launch PM. He does a bunch more, but I'll let him say it, Dean, on. So Dean, tell us who you are, what you do, and then we'll dive right in, I guess. Awesome. Yeah, I'm Dean Haddock. I'm the group product manager over platform and hosting. So, uh, hosting, that's our launch product. That's what we're here to talk about today. Yeah. Um, and then I also work with like shared services that uh, our different products leverage across the platform like our data layer, our security layer, um, various things like that as well. I've been at Content Stack for a little over three years. based in North Florida. Uh couldn't be more excited to be invited to join you today. Awesome. So, Lo, did you have like burning questions in mind or can I just kick off? What do you think? What do you have? You can just kick off. We're going to be talking about cashing and cash priming. So, I think first let's talk a little bit about like what is caching? Why do we use it? Why is it important? Yeah, that that's a good start. And then we'll see what comes out of that. Yeah. Shall I take a stab at that, Tim? Yes, please. And before we start though, I think caching is the hardest thing in development. Just let's say let's start there and now we go. Oh, that's really interesting. That's a great premise to kind of start from because uh unlike you, Tim, I think our backgrounds are a little bit different and how how we got into technology and the line of work that we do. And I actually entered into tech from the systems engineering, network admin uh side of the house. So uh building mail servers, building servers to catch spam. Uh I started working back in like pre um Y2K times. So like I was like building networks and doing Y2K testing with like a labs of fun stuff. Amazing. Yeah. So thank you. So when Yeah, I dated myself there. Uh, yeah. I was just thinking back what I did before Y2K in terms of development and I think I just played one video game. That was my thing. Hey, that's cool. That's cool. Whatever gets you through the door. Whatever gets you started, right? Yeah. Exactly. Yeah. Yeah. I played some games, too. Um, but uh so from my perspective, like these are just sort of like functionally distinct parts of like network architecture. So caching might be a little bit uh more uh friendly for me to grock versus if you're coming from like application development it might seem something like oh I got to I got to deal with this extra layer. It's not really related to like the functionality of my app or so you don't you're not really thinking about that when you're thinking about the UX and actually building the components of your application. But caching is particularly in the headless world, but not just in the headless world. Caching is, I would say, these days absolutely fundamental. If you're not doing it, you're either paying too much for your server load uh or you're delivering a bad uh or slower experience to your audience. There's a lot of other things that that a caching layer can do that are really beneficial for an application as well that's out there in the wild. um whether that is for like an individual developer uh working on their own side project or whether it's an enterprise organization caching is going to be fundamental um but what is it okay so let's just kind of level set on that the way that I think about it is kind of like this it's it's like a shield in a way that like allows your content whenever it is created to kind of live at this highly performant geographic ically close to the enduser. Uh extra layer of uh uh just serving components frankly, but also it's functional and you can actually deliver application code and functionality to that cache layer. now. So, we'll get into that maybe a little bit too, but the idea is basically that when your components, when your site, when your web page, let's say, gets built, um, that whenever you cache it, it gets distributed out to this layer of a service that is designed to get lots of traffic really fast and to be able to just singlepurpose serve those static assets. Boom, boom, boom. Does that make sense? It does. Yes. So could a static asset also be an API result of JSON? Yeah. Uh so yes, it could be. You could you can cach that. I think in Nex.js apps, uh API routes aren't cached by default if I remember correctly. Out of the box, I don't think so. You have to add some headers. Yeah. Right. And there's probably a good reason for that is usually an API is going to be retrieving content with uh um in more real time or more dynamically, right? Like you might have an API that like I do a lot of like weather application stuff. I'm really into like weather hacking. So not hacking the weather, but hacking weather and weather data everywhere. Um but uh like so for example my API is going to be retrieving the latest weather data with whatever latency I'm getting from my upstream data service providers for weather. I'm not going to cache those API responses. If I am I'm not going to cach them for very long because I want the most recent data in that. So yes you can that you can also cach static assets. more more commonly seen in the web world, it's like an image is cached or something like that because you don't need to go to the origin every single time to grab the image from the file store. Just put it in cache because it's not changing at all. That's a very common cache strategy. And so is that let's say let's talk about this image because there was a case on one of the the hosting providers that we don't need to name today where somebody in their public folder put an image or video I think and somebody decided to put that on Reddit and I think 8 million people clicked on that video that was in that public folder of that project. And I don't think that was cashed because he had a bill of $400,000 overnight. M yeah so and explain how caching would work in that context but also perhaps if I have seen that video does my browser cache it for me or like how does that work what is all that yeah that's a really great question and I think the answer is kind of it depends like I don't have enough I don't have enough information to like diagnose what happened there but um let let's let me not speculate right um but essentially um v video is is a harder nut to crack, by the way. So, it's a stream and stuff, right? Yeah. I wouldn't necessarily start with video when I'm talking about caching because you've got all kinds of different implications with videos. Um, yes, the streaming is one aspect. Like, are you just downloading the file asset? That's kind of another way to think about it. Um, but then also it's just like the files are so incredibly large. um like it's it's kind of on the more complex side, but in general uh you should be able to if if you're if you're hosting a file on a public folder, let's say an S3 bucket, yeah, you can cache that file and at the caching layer, that would be saving you costs, right? If you're if you're paying for every single access or whatever to wherever your file is being stored um and you could move that into a caching layer that is you know designed to scale and not charging you per individual request then that's a great way to save costs for example in in that model. Yeah, it sounds like that that asset was not being cached because it's video. That's it's a hard hard video on its own. You could you could cash the chunks, but let's not go in that today. That's really crazy stuff. Very interesting use case. It's not what most of our audience is working on. Exactly. The thing about caching I find most interesting or either struggle with sometimes is like when you're implementing it like how do you find the balance, right? Because you don't want to be too aggressive but you also don't want to be too conservative. So what do you think Dean in terms of like your approach to that? Like how do you weigh and decide what to cash and what not to cash? That is that is an awesome question and the easy quick answer to that is going to be you want to cache the right things not everything typically. So similar to what we just mentioned about the API routes if you're caching your API routes and you're wondering why your site's not updating with real-time data that would be why. um unless you're revalidating the cache of that endpoint. There could be again there could be a rationale that you would want to uh enable that kind of functionality with an API route. But um I I think kind of stepping back a bit um when we're talking about the let's let's set some like like contours about the the space that we're discussing. So we're talking about primarily applications for headless websites. So talking about NodeJS apps, we're talking about uh application frameworks like Nex.js and Nux and Vue and all these fun things. Um, and when you're hosting on launch in particular, because bringing it back to our hosting product, which is probably most similar out there in the world to a Versell or Netlefi, it like in the same in the in the sense that it accomplishes similar things for the end user where you connect to your GitHub repo or you upload a file with a zip or you upload a zip file and you deploy your code and it builds on launch and then it's hosted on launch similar to like one of these other platforms. they all do different things and do them in different ways and they bring different sets of functionality depending on what the user is looking for. So it's not apples to apples across these platforms but we're in the same in the same general ballpark. Um so with launch you've got basically think of it like this. You've got your your origin where all of your content lives and is dynamically built. This is behind the cache layer. this is like kind of exposed and not um directly access to this is not mitigated through uh cache necessarily. Um but then you have this extra layer of caching. So your origin's here, your caching layer is here and with launch um just kind of default out of the box um whenever you build your site the first person to access that site is going to hit the origin because that that particular object that asset that web page it could be the web page it could be any component from it is not yet cached for that end user. So this user makes a trip to the origin. If it's a dynamically built page, that page is going to render on the origin and then be available at the cache layer. The user will be able to access it. Now every subsequent visitor after that will uh get the cached version. So that first user has a slower uh a slower response time typically from the origin and then every other user gets the fast low latency high performant um cache version of it. So when you're asking the question of so what should I cache what shouldn't I cache the easiest way to answer this to me is like if you have assets that aren't changing a lot then those are obvious ones. If you have pages like your about page or your contact page on a site that aren't changing very often, then those are great candidates to just kind of cache it and forget it, if you will. Yeah. Now, every time you rebuild your site, your your cache is going to get um revalidated anyway and just our default settings. Um so your your cache will revalidate like that and then you could also revalidate through all the different mechanisms which we can go into um that we make available through automate and that sort of stuff. You have cache control headers that you could set on your application. There's a big world there. But in general you're probably not going to cache everything. you're going to cach things strategically um based on how much they're changing and uh what I would say like what the what is the uh what is the point of that particular part of your application? Is it part of your application that's constantly updating? Is it an API route? Is it just a static page? Is it a static asset? You have to think through these things when you're architecting your app. Yeah, totally. And there's one. Oh, sorry. Logo. Oh, I was just going to say like what you're really talking about is like knowing the difference between like your static and volatile content, right? So static content is stuff that like doesn't change very often and volatile is something that you would update all the time or frequently, right? Like think of like a CTA or some kind of banner. Usually banners don't stay up very long and if they do, they change to something else. So knowing, you know, about your general content ecosystem, I think is super important for this. Yeah. And I can also add like even if something's going to be changing frequently, it doesn't mean that you shouldn't be caching it. It just means that you might need to revalidate the cache more often uh every time it changes. So my question, that's why I interrupted because let's say you do change your homepage five times a day. That sometimes happens, right? Newscasts, whatever. But you have 50 million users that visit your website every day. If you don't cash because it's changeable, you're gonna lose a lot of patience with your end user, I guess. Oh, yes. How do you do that? Well, so great question. So the the way that that is done and again you probably are going to want to cache a lot of your site and the if you are just kind of using native functionality out of the box you're building a fairly generic app and you deploy it on launch let's say it's an next.js app then whatever cache control headers you set I mean the application's going to honor those. So fundamentally, if you set something differently, then you're going to have a different experience. But you build an app, you deploy it on launch, and by default, everything is is caching as soon as users are accessing it, right? Except for those API routes. So that kind of default configuration makes a lot of sense. It's really more that kind of API route is really where you're starting to think of like wait should I cache this because it's its intent is to give me uh the most real-time data or should I cach it but revalidate it every 5 seconds so that um it's not necessarily making a trip to the server every single time it's accessed which could really balloon my costs consume a lot of resources slow things down trigger autoscaling those sorts of things. So you can you can calibrate each of these each of these parts, these functionally different parts of your application um to to be cached in a rational way for your end users. But Tim, I want to go back to the the homepage because I think this really kind of starts to touch on why we're here to talk particularly about caching and talk about cash priming. Exactly. We're landing on the subject here. Just warm up to it. Building up a lot of suspense, too. Um, but you, yeah, you get millions of visitors and you're changing that homepage five times a day, 10 times a day. And kind of, it's easy to like dismiss. Well, this is a thing that we have to do and we just have to tolerate the fact that these pages aren't going to be cached until that first user accesses it. And I keep talking about this first user. We call that the martyr user. But it's not just one user. I was actually talking to our engineers uh this morning. By the way, Launch engineering team, I just really want to shout out to those folks. They are awesome. I absolutely love working with the engineering team on launch. They are some of the best engineers I've ever worked with. So, thank you all. You know who you are out there. It's a big team. I won't list everybody, but I just really want to take a second to to uh thank them for how incredibly awesome they are to work with. But we were talking about this this morning in that when you access that page, that martyr user is actually not just one martyr user. So, this is an important thing to grasp that when you go to access, okay, so I I I published some new content and I update my homepage. Okay, so maybe I just updated a blog post down here, but I have to update my homepage too because I need that blog post to appear there, right? So that new content needs to get cached when it's published and I need to update my homepage also to make and make sure it's cached. Now when that first user accesses the homepage out of all those millions of users what's happening is for however many seconds or milliseconds it takes to build that page every other user is also a martyr user during that time. So really we want to think about the martyr user is there is going to be one single user that hits the origin and triggers the caching of that page. But in that span of time, every other user that accesses this before it's cached is having the same high latency experience. And this is just part of part of today's uh hosting architecture where you've got an origin and you've got a caching layer. And until something is cached, it's not cached. And so what everybody deals with today is when we publish that um well, I'd say before today, not after today. Yeah, here we go. Here we go. Published. We just take it on the chin that there are going to be some users, a small small percentage of users that out of out of the total that have this slightly degraded performance. And we just say that's acceptable because that's how caching works. But it could be hundreds, thousands, tens of thousands. In a site that gets 5 million views a day, it would easily be 10 to 100,000 users who might get depending on the complexity of that homepage that's being rendered uh with that new publication. You could be talking about like 10,000 people who go to that page and bounce because if your page load takes longer than 3 seconds, you're going to lose at least probably 30 to 40% of your visitors at that point. What if there's a buy button on that page? You're not going to click buy now. But you're gonna go find it on someone else's page. Is exactly. And so this is and I think we should highlight because you just highlighted your tech team, right? Um content launch actually has all this functionality, but then on every cloud out there on the big clouds at least. Yeah. And that's not a thing that we see around in our space. You can actually use content stack launch on AWS but also on GCP or whatever you want and that's actually a huge thing because building this cache priming thing across these different streams is actually quite hard right yeah I mean launch like you said AWS Azure GCP we have full par across all these uh all these hyperscalers and what's interesting is the architecture is somewhat slightly different um under the hood because you have Lambda on AWS running serverless functions but you have different serverless function uh uh implementations on Azure and GCP it's called Azure functions or something and it actually works slightly differently with an even runtime even exactly yeah so the launch engineers have solved this have solved these problems and we actually have uh performance par nearly identical like I mean practically identical across all three hyperscalers as well. Um so yes launch and and again out of the box caching is nothing new for launch. We have the best CDN on the market. Um from our perspective and it's a very robust uh CDN. It's not a secret. We use Cloudflare under the hood for our uh for our CDN. Um but our users get uh WFT built in as well out of the box. So, DOS protection, all that kind of good stuff as well. And now, can I announce it? Can I announce 23 minutes cash priming? I feel like we need some like sparkles or something going. I don't know if we have anything. We don't have anything. So, cash cash prime, that's all right. We'll go back in and edit it later. Um, so cache priming is essentially uh at build time you can pre-cache that page. So it sounds very simple and you know kind of like an obvious thing that should have always been there um for for anywhere in this application but the impact of this is actually not to be understated and this is a pretty unique feature out there uh in the world of headless hosting. In fact, although there are I think Tim, we've been talking about like how other platforms may or may not be doing something similar, the way to think about uh cash priming on on launch is essentially that it's intentional and you know exactly what you're doing and exactly what you're caching. So, practically speaking, you specify the routes that you want to uh cache at build time and then launch will do that for you. So no more martyr users. Every user gets the same experience. You publish to five million or you have five million people visiting your site every day. You update your site that homepage five times. Every single user who accesses if you use cache priming on that homepage, every single user who accesses that page is going to have a similar uh high performance experience getting the closest point of presence to them at the caching layer instead of going to the origin. Yeah. And the fact that you can have so much more control I feel like uh in the way that we do cash prime in particular it gives you an opportunity to do some like prediction and an and incorporate some data and analytics right so you can take a look at for instance like where are the most frequently traveled spaces in your website from your analytics and then you know oh these products or xyz are really popular I want to cash this so I feel like the more control you have the more you have the ability to not to be proactive, right? Absolutely. Yeah. Or imagine you have a big sale coming at a big holiday, shopping holiday or something like that, and you're going to publish a bunch of new uh uh you know, products or something like that, and you want to publish them all. You set them all to publish at XYZ time. Well, now you can also pre-warm the cache of those pages to make sure that um when those new pages are published that they are also cached and everybody gets the same access. So, you're not risking uh 30% of your visitors to all 100 of those pages potentially bouncing uh you know, heaven forbid they're on mobile and get an even slower experience. And then, yeah, I mean, I don't want to oversell the concept. I think the concept is awesome. Um, and by the way, that came through the launch team. It didn't come directly from me. I worked with the team to make sure we brought it to market. Um, but that's the level of engineering that we have on the launch team and really thinking about these kinds of real world problems that that we're everybody's just kind of settling on today. Um, but the uh uh yeah, let me let me just leave that thought there. Yeah, I also think it's interesting in terms of cash priming, right, to think about like equity, right? uh particularly like thinking about users who are using uh lower cost devices, right? Caching really helps with that and most people are using lowerc cost developers. Yes, we all have thousand thousands of dollar computers, right? But not everybody does and caching can really help with user experience if you're on you know a lowerc cost developer that maybe doesn't have enough me uh you know a lot of memory or processing speed, right? So I always think it's really interesting to think about that. Well, kind of right. Yeah. Well, the way that I would think of it is or or I would say a little bit more uh like matterof fact to me is that um the uh caching infrastructure that launch uses um we there's a concept in caching called the edge which is essentially the the edge of the environment that's like as close to the end user as possible. um you know without getting like right on their machine. And if if you're caching your content and it's available in all these different points of presence, you're going to have a much faster trip, much lower latency to that server to get that content. And so that end user, even if they're geographically very very far away from the origin and there has to be multiple multiple hops until you get to the origin, this user will have a much more performant, faster experience. It'll feel like the server's right down the street. And in some cases, it may be. Yeah, it might be. That's interesting because I live in the countryside far away from everything and my internet is really fast because there's a data center in Paris which is a few hours away. So, it's it's really um it really helps to have cash there because I've tried it out where I would try some hosting servers but didn't pay and so then the origin would be in the US and the CDN would be in the US and then my roundtrip was still like 500 milliseconds even though I was on the fancy CDN. So, yeah matters, right? It's really good point. Yeah, geographic proximity is more and more important in the web, which is kind of an interesting concept because the whole point of the web once upon a time was like I just spin up a server in my closet and anyone in the world can access it. And how cool is that? And these days it's more like very cool going on on your server. you now need to put as close to every single person as possible so that they can all have the absolute best performance. Um, which is, you know, I mean, yeah, a fun problem. It's a fun problem to have. What what this leads us to though is edge computing, right? My next question. You just went there. Go. I like So now you can also we have edge functions as well. This is not a brand new concept but is something that launch offers as well but you can run JavaScript uh on the edge like at the CDN level very very close to that end user. So I could like write some code deploy some code uh edge function code that looks at your um you know your device uh or your um I mean just about anything really. Like I could look at your ge your geography where you're coming from. I could look at what um uh what operating system you're using. I could look at what browser you're using. I could even interact with an API at that level and serve you different content based on certain characteristics like if you've heard of I'm sure you all have talked about um litics and uh personalization all that kind of interesting stuff that's happening at content stack as well. These days, we leverage edge computing to be able to deliver a flicker-free personalization experience. So that basically the three of us, we're in three different geographies. We access the same site cached locally to us running edge code and all three of us have a different experience but with the exact same identical performance um because of the power of edge and how we're leveraging caching. Yeah, that's that to me was like when I noticed that that started to change this a few years ago when these edge functions started to happen. There's so much you can do that you don't even realize now. Like I once had a project where we would get the HTML stream from the user at that at their location and then look at certain HTML tags and replace them with personalized data in the stream and we would then stream it back while replacing. And so we had a 30 millisecond page load that was fully static with a few things swapped out on the edge with JavaScript based on their location or whatever. Man, that changes the game. Yeah, it's really cool. But it's really hard to explain and then see the benefits sometimes because there's so much else. Like we like this is not that stream, but for example, what we did is let's say you had a legacy website that was super slow. You didn't like it anymore. We wanted to make it fast with a few changes on the edge. We would grab that legacy website and the user would go there on the edge with there the proxy then by the edge and then we actually build a visual content editor on the HTML of that legacy website on the CDN edge. So you could change it visually just changing HTML in the in the CMS. Hit save and then on that edge for the user they would see that proxied website with the changes you just did. Like I took like five hoops through a hoop and jumps and to explain this, but this is super weird, but you can do this now. Yeah. I'm not saying do it, but you can. Well, I think kind of like AI, I think edge computing is one of those things that the its capabilities and what it stands to offer and the benefits that it it, you know, could be giving are not fully realized yet. like the world is still kind of wrapping their minds around and other things in the market and in the ecosystem are also evolving too. And so like I really see edge as being like fundamental to IoT or internet of things and that sort of stuff but we're not quite there. I mean there is definitely a lot of use of that today. I can't think of any examples offhand but most of them go to marketing for me. Um, but the um just like I I think that we're gonna see more and more use cases. There's some very vanilla, very straightforward use cases that Edge is awesome for in terms of like solving existing problems, but the potential of what it can offer, I think is yet to be seen and I'm excited about that. Yeah. Shall we have a look at some how we implement the cash priming? Yeah, I think so. We've been talking for a while. We're already like 33 minutes in. Yeah. Let's look at some code. So we just have a look at how that works. Like let me just share this and well we just landed right into my code editor and this is something called launch.json. And so when you deploy a project on content tech launch it will just look for that JSON file and um Dean refresh our memory is there other stuff that can be put into this JSON file already or is this the first feature where we use this? Oh no great question. So we have rewrites and redirects are already there in launch.json. Yep. So you could you could roll your own rewrites and redirects at edge, but we just build that functionality for you using launch.json. Um yeah, I could just do something like and then do a whole bunch of URLs here. Exactly. Yeah. So these rewrites and redirects are are really useful. And I don't know if that's the exact syntax, but no, this is what AI gave me just now. I don't um but and our docs on launch are excellent. So anything that Tim is showing you here, you will be able to find on our doc site without issue. Um but but yes Tim uh and that uh that rewrites and redirects functionality is really useful for migrations particularly portions of a site or a multi-sight network over in uh chunks. Uh that's a really good way to make it easy. Yeah. And so what you're seeing here is that of course I'm using cache priming and these are the URLs I want to cache prime the moment I hit build. And so actually not like looking at this now, we don't really need all of them to be cash primed. Actually, the our story page will likely stay the same. So this might not have to be cash primed, but like our products definitely, right? So there's a bunch of different products here, category pages, stuff like that. There's not even that much to it because this is not a super big project, but when you have a look at this project, oh no, Chrome will relaunch. Don't do it, please. Okay, we're good. Hours. Yeah, exactly. We're good. I just clicked, okay, go away. You're like, "No, no, this is not that moment." So, basically, this is one of our this is like an e-commerce luxury website. And so, you can you can go and, you know, shop earrings and, you know, let's say this is your favorite earring or for example, we did, let's say, a Valentine's campaign. Let's say this is I have to Oh, no. We're looking at not Valentine's right now because it's personalized. Welcome to how that works. Give me one sec. So, basically, imagine you have a Valentine's campaign, right? And thousands of people are going to go to your website and here we go. Go to your Valentine's campaign and this updates all the time because you you have like a special revival Valentine's set that you might update once in a while or there's different copy or different stock or whatever you have here. So if there's millions of people here, you want to when you update cache prime this page especially, right? Yeah. And so right now when you look at launch, this is just one of our um uh environments. So we have this is let's say the production and so for the final deployment here. We can have a look at the bottom. So it just built your whole application. Maybe have to zoom in a little. And so what you see here is like it found 40 URLs for cache priming and then it just did all the things. It actually cash primed and then at one point it says, "Oh, I actually found 40 of your URLs and I cash primed them." And so Dean, can you explain a little bit more technically what this actually does? Like does it just ping a URL and go away? Do you have like a bot that crawls the page? Like what do what do we do? Well, I won't go into too many of the details, but essentially just like when the uh content is built, when each of those URLs are built, they're sent directly at that time to the CDN. And the and the CDN is multiple layers of caching. You could imagine like Cloudflare is not just like uh a whole bunch of servers distributed and things are either cached on all servers or not cached. There are multiple layers of redundancy built in here. So this will take you to that first layer. And so everything is there and available in cache. So once other users are accessing from around the globe, uh the caching is still going to propagate out to all of the points of presence because I mean there are innumerable points of presence. Yeah. So you just kind of give them to the CDN and then they take care of the rest which is kind of nice. We can just use an API ourselves, I guess. Yep. That's right. And and this is cool because previously the same thing happened, but what triggered that caching of that content was a user hitting that content exactly rather than us. Yeah. And it makes sense, right? Because if you're Cloudflare, you're like, well, why should I cache something that nobody is accessing? Doesn't make sense. On their scale, it's very expensive. Exactly. But if we know that something needs to be accessed because it's our website, then we're in a great position to say this should be cached immediately because this is going to be hit by somebody. Exactly. Exactly. Control to turn it on. It's literally just this button. It's so easy. It's kind of cool. Yep. You turn it on there and then you implement it in launch.json as you mentioned. Yeah. And then here's the docs that you I think already shared. Hello. But um what for I just did the general one. Can you post that one in the chat? I will. Thank you. And there's some FAQs as well that are worth looking at for folks who are curious. Yeah, there's a bunch of cool stuff here. So there's one thing that for me was very important. Like this website already has like if you look at our products and this is just a little demo. There's a ton of products already. And so I didn't want to by hand, you know, put this all all all in my, you know, JSON file because then I would have to just open all of them, get my URL and then paste it into my JSON file. I didn't want to do that. And so I took a little bit of um crude way to do this because I just said give me all URLs. I don't care because this is not a big project. But you can of course curate it a little bit. So what I have when I actually hit npm run build this is also what you actually saw here that that's what this is right if you run npm run build all this stuff happens and so what I now have in this whole scripts thing there's a pre-built function that is fired and so the moment it launch hits mpm run build it looks hey is there a pre-built thing yes and this is just a javascript file that is just updating launch config.js which u it's called mjs because I wanted to use fancy modern JavaScript. Let's not get bogged down by that. Yeah. Um no worries. Let's just not look at that. Um so essentially what this is doing is this is a function that is fired before the website is built. And so it actually looks at content stack. It gets all its environment variables to figure out, hey, let me connect to content stack. And then I'm going to query all the pages, all the products, all the categories and all the product lines. But I only want to get back the URL, please. So this is basically all the page entries and only give me the URL for that page. And so it finds it all and I map whatever I get back into just a list of all the URLs. And you can see I do slash products myself because this is a hard-coded um item. So when you when you go to for example slrs this in this case is an Alolia integration that you cannot really do anything from in the CMS. I chose to code it that way. So that's why I hardcoded SL products here. And so what it then does actually it finds if it has a launch.json JSON file in the in the files of this project and then it will just write whatever came out of this function the get all links and it it just writes a file into the file system that then becomes launch.json and because you do that pre-built when launch starts building the project it has the launch.json JSON file to detect and just does something with it. And you can is if this file becomes super big because you might want to, you know, have 10,000 links in here. I'm not sure that's the way to go, but imagine you don't need that file in your um codebase because it's all just generated. And right now, I put it in here, otherwise I couldn't show you, right? But normally you might want to choose not to do that. Um Lo, did you want to say something? I was just going to say and this is like the perfect example of when you do want to think about caching volatile content right because this getting all links that as function is perfect for like if you want to tell it to do that to all your campaigns right for instance yes it's volatile content but you also know that it's probably going to have a lot of high traffic exactly yeah you don't want to have that stuff but like what you can see if you do if you actually run this build locally I'm just going to show you here but this is what launch also does you can see that launch.json updated successfully. So that's how fast that was. It just almost instant. And you know why this is fun? The endpoints for content stack for all these pages are cached. That's why this was so in look how fast that was. It was literally instant. So I love that you brought that up because you know content stack is not just one API where you're accessing content. We have the management API, we have the delivery API, we have images API. Exactly. Lots of different APIs, analytics API. There's lots of very cool um APIs out there. And this is a really great example. I also love the pre-build and post-build scripts are kind of one of my favorite parts of of building because I think we think so much about the, you know, the core functionality of an application, but there's a lot that you can do um by running operations, running certain jobs pre or post build. And this is a great example because what Tim's calling out here inside those entries there is a URL field that is visible to the content editors and that is a knowable piece of data a piece of metadata for your entries. So all Tim is doing is from one content stack part of our content stack platform to another part of our content stack platform introspecting into those entries in order to inform uh the application to what content exists. And the cool thing that Tim has solved for here is that when the content editors on their side are adding more content, they're adding more products, they're changing the about us page, the, you know, all these sorts of things. When Tim runs his rebuild, whatever new URLs, whatever new entries have been created, whatever new products have been added will be automatically added to that list. So there's doesn't have to be like a ticket submitted by people involved. Yes, it's just done. And what you can even do later on is set up a web hook that says if I hit publish on this thing and I go to production that then because of that automatically launch would just rebuild. Yep, that's also a thing you can do. And so sometimes it might not have to rebuild the code, but it could only update the launch.json or there's a bunch of options here that it's not really for today's stream, but it's interesting. And I just wanted to quickly show you how fast this actually is, right? So there are four queries going to different content types here. So four queries at the same time basically, right? We're using a promise here. And so this is how fast that is. When I run this script, it literally just did four queries and the whole file was already rendered. This is it's basically ridiculous how fast this is. All thanks to caching. Right. Yeah. So, I have a question, but perhaps I'm thinking about this wrong. So, when would you decide to do a pre-build versus a post build? In this case, it's very simple. The pre-build needs to be there because if I do a post build for this, when launch starts building, it needs to know that there's a launch.json file to be able to do the cache priming, right? If that launch.json JSON file comes after the build and post build launch wouldn't know it has to do something with cache priming because the file isn't there at the moment you start building right so in this case it's a pre because we need the file for launch to see it prior to yeah okay it's that simple but there's a lot of stuff you can do post build as well like if you look at this I have a bunch of other things here as well like for example I have simulate traffic because this This demo was specific to also have a look at our personalization stuff. And so what I wanted to show you, I can show it quite quickly because we have a little bit of time, not too much, but you can Oh, I have to go back to my stack here. And how about we do this for a second? This is nicer, right? Um, I have an audience app here. If I can get there. No. What's happening? I didn't do anything. I'm here. So, pains me to see that. But you did not see this. GA. So, this is a good catch live. Anyways, what is interesting here like this is basically looking at I'm zooming in out just a little here. This is looking at the data of the visitors of our website to look at what are they interested in. And you can see there's a very big intensity on tech optimism because all these product lines are actually technical, right? This is um circuit color necklace or data drop earrings. So, it's all about, you know, optimism and tech and 2000 revival. But then you can see there's a bunch of people who like silver and diamond. And I could actually make an audience here to then start personalizing towards silver um lovers. I also have one for gold. And so I needed a bunch of data for people to be able to even do this, right? So if you look at, for example, when we go back to May, something like this. Well, and we go to beginning of June, maybe something like this. This is where I got most of the visits. And you can see, oh, wait, I have to go to May 28 here. Sorry. Here we go. You can see the difference of almost no visitors to my scripts running, right? And then faking the visitors. That's what we're seeing here. And I didn't code my script very well because most of the visitors actually went to similar pages. That's what this shows. But to make a long story short, when you look at my scripts for this is my simulate traffic right now, I kind of just did it separately. But this could be a if you wanted to do this for every release, this would be a much better postbuilt one because then you know the thing has been deployed right everything is built the thing is ready post is and the build says okay I'm done then you simulate the traffic right and this is just some scripts that I fcoded to literally just uh I actually asked can you just you know make me um a bunch of people that go to earrings pages or run profiles and can say how many visitors and all. This is so much fun. Of course, this is just me going on a tangent here, but you could definitely use a post build script to run something like this. In this context, do it. Normally, never do it because you're skewing how your personalization data looks or Yeah, don't do that. Don't do this. But, you know, in this context, this is the way. Yeah. Very. So, are there like we're nearing the end. We haven't actually had that many questions from our lovely visitors or viewers. If you have any, feel free to ask. If not, Dean, is there something burning that you wanted to talk about here? Is there something final thoughts, things, or anything like that? Yeah, probably more than can fit in the remaining time allowed. Um, let me say this. Um, you know, there is a lot more cool stuff coming with the launch product and this a lot of what you're showing here, Tim, there's some interesting things we're discussing that further kind of build into that introspection over into the CMS and how we might, you know, make those things a little bit easier even than what you're describing there. Maybe even a little bit more automated. um because we do have access to those URLs because we're sharing DNA essentially by CMS and launch on the same core platform. Um so there's some neat things that we can do there as well um and and automate as well as a tool being part of this chain. Uh there's more features and functionality coming in this space. I can't preview too much of that um for you today, but just know that we are uh kind of bringing it back where we started. Launch has been built and deployed on all major hyperscalers, which is a huge part of um our plan for the launch product in general. Now we are at the point as you're seeing with uh cache priming to be adding more and more very interesting differentiating and unique features for developers who are using our platform. Um what that uh what that means uh you'll have to stay tuned for more uh streams like this to learn about it. Um, but just know that from our perspective on the launch team, this is really only the beginning uh of tooling like this that we're hoping will really make some big um splashes in the market, giving developers more options and more tools to work with to deliver the absolute best experiences for for their front of house and back of house folks who are needing to interact with their applications. Yeah. Because imagine you because we know about your data and your content and so what if we can look at analytics of your visitors and then show that in the CMS. We have everything we just combined and I know for a fact then you work on this kind of stuff like there's so much here that we can do that is really interesting. Yeah. Good times. AI automation hosting I mean you can dream it like we can do it. It's really just a matter of time and putting the pieces together at this point. And the cool thing is as you've demonstrated here and maybe this is a great takeaway from my perspective, one of the most amazing things uh when I joined content stack and started learning about all the uh you know ins and outs of what we do and how we do it. Um one of the most exciting things to me about this platform is that I don't have to wait for content stack to build a feature. If I can access the APIs, I can build I can build my own UI to manage content entries if I really wanted to. There's nothing stopping me from doing that. And by having API first access to all these different parts of our platform really like our only limits are our imaginations in terms of what we can deliver and the types of problems that we can solve for the modern web web using these tools. Yeah, it's pretty interesting, right? when people ask for features they're like oh just build it and then in 10 minutes we can actually kind of just make an automation and a quick you know developer app and suddenly it works so that's that's where it becomes platform rather than CMS but also not to be the naysayer but you should also think about just because you can should you right like for instance you can build your own entry system but then you have to weigh the opportunity cost of that like so what is your maintenance like? Do you have the actual resources to maintain that? That is a very good point. Uh yes, just because you can does not mean you should. And you know if you are uh trying to you know build your own bespoke uh way for your internal users to leverage part of content stack that we're already providing for you. Just know that building an application is really just kind of like the first 10% of the other% is maintaining it in definitely. Exactly. Every time people ask me why did you build that? And I just say because of reasons, right? That's it's not enough. But I'm a developer. Let's go. Let's develop. As soon as you develop as soon as you deploy it, then it's like, oh, well, I kind of like that button more over here. Would you? No, I like it back on the other side, etc. Make the logo bigger, please. Kind of thing. Yes. Um, I think we found a natural stopping point. Lo, do you have any last thoughts? Um, no, just the requisite uh shout outs and uh yes, we go promotion. Uh, thanks everybody for joining um content polls for developers. Thank you so much to our special guest Dean. You rocked it. Uh if you haven't already, please join um our Discord community. You can find the invite at community.contentstack.com. Um also we have a great content stack author program. Um anyone can apply to join that. Um and there's compensation for your articles. You can write anything from thought leadership to conceptual to tutorials. Um show off things that you've built with content stack. It's a really great program. We help you get experience with writing production ready content and blog posts and tutorials. So, please join if you're interested. I will drop those links in the chat as well so everyone has them. That's it for me for all the promotion. There we go. We always have to get this out of the way, but it's really important because these things like this, for example, this author program, if you get low to be your editor, you should do it. Like this is a thing. go and learn right to be fair I will be editing it so you will get every time you know but then we all Dean is also a good editor but maybe we shouldn't say this because then he gets Dean has other stuff to do we can't throw anything else actually one of the hats I I wear here is that I do get asked to write an article now and then and have one white paper out there about building scalable DXP and then have another white paper coming very soon but I won't preview Excellent. Yes, we've written we've written an article together. That's right, Lo. We did. One of my Yeah, you did. Um, thanks everybody for watching and thank you again, Dean. This was a whole lot of fun and we'll see you next time. Yeah, everyone. Take care. Oh, Tim was asking about a date. Yeah. Do we have a date yet? I don't think so. Right. Somewhere next month, probably. Yeah, somewhere next some after the US uh Fourth of July holiday. Probably that next week. Yeah. All right. Awesome. Thanks everyone. We'll see you soon. Bye.