Next.js 13: Data Fetching Strategies

Hello, everybody. Welcome to our workshop, React Day Berlin, about 9CX13 and data fetching especially for what concerns the new app directory. I'm Alice De Mauro, I'm a sales engineer at Vercell, and a sales engineer means basically that I am a solution architect for pre-sales.

So basically, I check the architecture of our customers and I see if Vercell is a fee. What is Vercell? If you don't know it, we created and are maintaining SGS. Webpack, we have people working from Webpack and we just released TurboPack. We do also have in-house TurboRepo and other tools that might be useful for developers, in general, if you don't know us, we are the creator of the legendary Next.js, which is the framework for React.

I'm going to immediately start with what are our prerequisite basically or what at least I'm going to use for you workshop. Something that I'm going to do pretty often is this movement here. I hope it's not too jarring, but I'm really used to go for my environment like that. What do I have? I have my ID. I have my terminal and my Visual Studio code. I do already have some code prepared. The code is going to be at this place.

I'm going to actually give you two links. One is going to be the clean code before the workshop basically. I'm going to drop it in the chat. This is public and you can just access it. I simply forked one of our famous repositories for the playground for Next.js app and just tweaked it for this workshop specifically. What I'm going to do is to actually use the pull request to welcome to our workshop in order to paste or to deploy our changes. All the changes I'm going to make, you're going to see them in this specific GitHub branch. What also I'm going to do, I have my Vercel dashboard. I created a ProTrial just for this workshop. Why? Because I needed it to have all preview comments enabled for you. If I go on my deployments, I have my preview. My preview is based on the welcome to the workshop branch. Basically, here I'm now going to paste this one. If you are logged in in Vercel, you got to paste it here. If you can login in Vercel, then you are able to actually comment on everything that is on this page. This is going to be our workshop baseline.

For example, I can do this example. I'm going to see your comments. If you don't have Vercel yet, consider that I had OBI just, I don't know, yesterday. I think yesterday I had OBI. It's super easy, you just continue with GitHub, you just login into GitHub and done. Same for GitHub and Bitbucket. Then you can comment on this specific URL. This URL will also leave after the workshop. Don't worry about eventually things that you forgot to ask or that you don't want to ask now because you want to check things further later on. Please just go here and comment. I'm going to receive them directly on here. Then the comments, they're going to see them on the Versal bot. I'm going to simply check them here. I think for what concerns what we're going to have, more or less, ready, it's done.

Something else. What is it all about? Our workshop will be about fetching strategies for the new App Directory. I'm going to show you server components, which is basically the default for the new Next.js. Client components and how to do it on SUR. Disclaimer is like you did it before, nothing different. Dynamic fetching, and how does it work when you opt-in, when you opt-out, and these kind of things.

ISR, we provide that out of the box. It's pretty powerful. If you didn't try it, try it. On-demand ISR, powerful again, very, very powerful. That's probably the longest piece, because to set up on-demand ISR is a little bit more work, not too much, but still, but that's gonna be our most longest probably, and then how streaming works. So our suspense works in general, because that's from React, and how it will work together with Pagesy. These are all fetching strategy, can be like from the data perspective, they are tightly coupled with the page perspective, is also how the pages and the routes are rendered basically.

Just so you know, if you don't know Next, or you never used it, we just released Next 13. The app directory is not the only thing that we released, of course. There's gonna be also a lot of others, for example, TurboPack, or the image, the font, and so on, the scripts, all integrated and enhanced. So if you don't know, or you want to check more, just, you know, I pasted there the link. We also have the, I'm gonna fetch them right now, the Beta, this is specific to the fetching, data fetching strategy. But in general, we do have the Beta docs. If you are logged in in Vercel, you also can comment on them. So if you find something that is not clear, please give us feedback, you know, anything that is useful to enhance our docs, it's always good, especially if you're expecting something that's not there, please just don't be afraid to paste a comment there, you just click on these little icon and you can just comment. And we answer, so if there is some, you know, things that it's not clear on the docs, we do answer questions in general.

So back to the code. So I have my IDE here and I'm gonna have some code already done because of course, part of the fact that I'm very clumsy with my hands, so I tend to do a lot of typos, but apart of that, it's easier, it's faster, it's gonna be faster to actually paste the code from something that's already created, I'm gonna push this code anyway, so you're gonna have it on the GitHub account. First thing first, so, terminal, a nice terminal, two things that are very important. Of course, first thing first, you have to install everything, you're gonna use YARN. I usually use npm, while in my developer careers, I use npm all the time, but these days I don't know, I like YARN pretty much, so I'm using YARN for now, if you run YARN dev, so these are the two distinctive things that are very important. If you use YARN dev, you're gonna spin up the dev environment, which is the server-side rendering environment with hot reloading, so every time you change something, maybe super fast, and localhost, I'm gonna show you right now because I have localhost here, on localhost is gonna always show my changes right away whenever I do any change. Something that we're gonna use later on is really, really important to test all our fetching strategy, especially for what concerns the statically generated pages and the static fetching in general, is gonna be creating a production build. I'm gonna go right away to it because server components is one of these examples where if you have anything that you need to test from the static perspective, you will need to create a production environment and test there, because only there, you actually have the classic first build and then serve, right? For now I'm just gonna start right away. So I have my application here, the app directory is the new NestJS directory. I have everything in the package of JSON of course, and I do have some groupings. These groupings are not gonna be in your routing, they're just meant to tidy, to tie, sorry, your URL. So basically what I did was like, okay, I have a couple of fallbacks because it's of the loading pages and so on. Some youtube that I might or might not use, but what is important is our fetching. So from the root directory, localhost slash, we're gonna go through all these routing. Every single route is gonna be reflected from these names from the folders. This the same way a classic NestJS works. So server component is gonna be one of my routes and this is where I'm gonna start. I'm gonna go to my local host. So if I click on server components, which is the first one, you see server component is my, my route. So the name of the folder, exactly the name of the folder automatically done from next. Server components. So explanation of server components. They are running the server. They are gonna be always automatic. Pages and layouts are always, always server components. Always, they're gonna always be rendered first in the server. I will show you later on client components and, you know, how to divide the little pieces. By default they are steadily generated at build time. And that means that everything is gonna be fetched at the time you're gonna be fetched from the server. There is not gonna be any round trip from the client and the server. So there's not gonna be such a thing like, oh, I have the client, I have all my JavaScript and then I need the posts of my blog posts, right? And then I have to ask back and forth to the server. No give me this one, give me that one. So that's not gonna happen because everything is in the server, within the server and the server is gonna do all these kinds of fetchings without any round trip between client and server. And that's super, super fast because then they're already built.

There is no need to fetch more data. So that's why it reduces waterfalls. Something that I wrote there and I will write like that, it's remember to always have a production build disclaimer. If you notice that it's statically, is not statically generated, so it's dynamic. So for some reason constantly refreshes and I'm gonna show you how to check that. It refreshes, refreshes means or that you're running in dev. So it's just the dev environment or something is opting in for dynamic. I will show you dynamic fetching later and what does opt-in for dynamic fetching.

Dynamic fetching is where you don't have a cache. Every time somebody asks for your segment or route, segment and route is the same in within SGS, more or less the same. Every time you have a request it's gonna regenerate the page and recalculate everything, which is less optimized of course, sometimes it's necessary.

Okay, so I'm gonna start building my server component. What I want to do is want to show posts from just the JSON, classic JSON placeholder. And I'm gonna show you how they're gonna be just exactly generated like that. Server component. I have a dynamic route the dynamic route is gonna take the ID. So it's gonna be server component slash the number of the posts, one, two, and so on. In my page, there's just a description. The layout will wrap everything around. I'm not gonna explain about layout too much now because basically these is gonna be always the same. What I did here was just creating these little tabs and these tabs are gonna just be the same over and over within all the data fetching strategies. So the layout is what basic it is a sort of higher order component, sort of where you just wrap all the children and the children are your pages and all the other routing children of the other pages all the other segments.

So that's why when I click here, I still see the children which in reality is what is inside this ID. We'll see that that page is like your index basically. So it's your index.tsx and layout is the higher order component around and you can I'm not gonna go through it too much, but you can wrap around layouts and layouts and layouts and really have this isolated way to wrap your index pages through all your segments. So I already have this ready. However, I have still to create my index for this slash one slash two blog post. So the first thing that I'm gonna do, I'm gonna copy paste this piece of code to avoid doing mistakes also because it's a lot of code. So one of the things I'm gonna do is to fetch the title of my data. My data is gonna be the post, post number one, blog post number two, and so on. Something that I also do in all pages that I'm gonna create. I'm gonna show the date of the render. So what happens when you call this function is simply like paste a piece of HTML, right? And the HTML is gonna be the string of the date where that HTML is gonna be created. This helps to check, if is regenerated every single time or if it's generated only once, which is really useful. And you always have to create a new one because then you can really see is it being hit by my request or not. What is about data? So data is something I'm simply fetching from an API. Fetch data is gonna be a function and that function is gonna be the one that's gonna actually really fetching the data from the REST API. Params, it's automatic in pages. So when you have a page component from the naming convention page.tsxjs, it's the one. Params is gonna be automatically taken. And that's basically this ID. When I'm gonna have params, params is gonna have inside the ID. And I'm gonna also show you now when I'm gonna have the fetch data function. So I'm gonna now create a fetch data function. And the fetch data function is gonna ask for the params and inside this ID. This name is gonna be the same of these names. So if I would have called it blog post ID, then this one needs to be blog post ID. Because otherwise it's not gonna match the name. This all automatic right in NeXT. So NeXT is gonna be this by itself.

What fetch data does? It calls fetch. So fetch now in React, Classic React, it has been a name for being just, you know, the native fetch we did Dublin. Meaning that you can store these in the cache. So whenever you have a fetch anywhere, but that fetch will have the same input of another fetch, those are not gonna be duplicated. So that data is not gonna be fetched twice, it's also, it's always gonna be fetched once, and then the rest is gonna just fall back to a cache.

It's what the names meant was like fetch now, because it's gonna be server side, it's gonna be saved in a way that is gonna always retrieve once rather than multiple times every time you pull it. That's why it's better to re, let's say, duplicate the fetch for the same route, for the same URL, API URL, in multiple pages wherever you use it, rather than having it at the top of the pattern, because it doesn't really matter, and it's better to like, you know, isolate your fetching data in general.

So, in this case, this is the leaf of my tree, because it's the last route that I'm gonna receive, and it's gonna be, you know, where I'm gonna fetch my data. Next, did something more. So, because Next is on top of React, what we did was to enhance fetch with two things, caching strategies and revalidating strategies. So, you can write, I will show you later, but you can write the fetch in a way that you decide how cache will work for that single fetch or how revalidation will work with that single fetch, which is not native to React, so it's in Next. What is this gonna do is just like gonna take the rest, serialize it back to the data, and then I can simply have this data pulled in.

Something that I need, and I spoke with Tim Nelkens about this just like a couple of days ago, so when I created this specific example, it wouldn't let me, it was a bit more complex to this, so it might have been something else, but it wouldn't let me have it static. It will always be dynamic for some reason, so it was opting in for dynamic, and we discovered that we needed this function to generate the static patterns. It can be in two ways. You can all generate the static parameters for that route, or basically list them, say, hey, the IDs of this post is gonna be the one, two, three, four, right? And for doing that, you can still fetch, right? Again, fetch the post, all the posts, and then list them here in this way. This needs to be the same name of the patterns, it needs to be the same name inside these brackets, or you can just opt for just having them dynamically created as static parameters, because Next.js 13 is still in beta.

Talking with Tim Nirken, we were thinking, should this be default, because theoretically, this should be the default, right? You should just always have static parameters because this is statically generated. So, yeah, the idea here is like, okay, if Next.js 13 is still in beta, they are deciding what to do, but consider that if you see that all of a sudden you are opting out of static, for some reason, try this piece of code to see if it will reopt in. Again, I'm gonna leave this here just so you know if you want to just create all your blog posts, you can, possible. But this is more than enough to opt in static. My code is ready. Gonna save it. I'm gonna switch to my terminal. My terminal just hot reloaded what I just changed and within my server components, now I have my posts.

However, did I say that before? You can see here, right? This is the render. And you can see when I change, it's just right now, it's changing, 2703, 2705. This is dynamic. What else I can check, oh, so big. Is whenever I code, see, there is a 200 here. That means it's not cached. That means that every single time it's gonna ask, ask, ask again. Why? Because I'm in dev mode. So every time you're like, oh, wait, why is not opted-in for static dev mode? So I'm gonna kill everything and let me clear it out and just build and then start. So build will create an actual production builder. So everything that's gonna be statically generated is gonna be static. Everything that's still dynamic, all ISR, everything, and then start is just gonna start. The application, consider that it doesn't have hot reloading, of course, so I will have to kill it again when I will have to go to dev mode, or when I change something, I always have to kill it again and restart it because it's gonna produce the new pages. Done, so I go back to my blog post and then look at this number, it's not changing, why? Because it's not gonna refetch it, it's not gonna rerender it. And if I inspect, what you can see, 304, cached, cached, cached because it's static.

So these were server components, by default, they're gonna always opt-in static. And they're gonna always fetch from the server side. So the server is gonna do the work, no waterfalls, nothing like that. And to test it, you test the production view. We are gonna go in client components because something that, for example, on the beta dock is not there yet, they're just like, hey, go to the SOR and check the SOR or React query, anything to just ask from the client component for your data. In that regard, I wanted... Sorry, no, Google, no, no, no. Hey, Google, stop. I should have switched off Google. Sorry, guys.

Yeah, anyways. So client components, when do you use client components versus server components? So that's the question, right? You use client components when you need React or the windows. So everything that's client side to actually work because window is not gonna be in server components, right? Same ways that process.env is not in client components. So server components, process.env, secrets. All the things that you need to manage from a secure perspective as well, they go in server components.

Client components, they are running on your computer, on the computer of the user actually. So use the state, use the facts or the changing things that need to be done, they're gonna be in client components. How you fetch data? I use S Word, you can use, so React Query and so on. Remember that pages and layouts are never gonna be client components, they're always gonna be server side rendered. So consider that you cannot really make them. If you want to have a client component, you need to wrap it around a server component might be pages because pages is your index. In the future, it will be possible to, instead of using S Word, to use the use hook from React. However, it's still not implemented in S13 because, yeah, it still needs to be, of course, implemented because it's in beta. Always the same.

I'm gonna do the same. So the code is gonna be very, very similar. Let me go to client components. Very, very similar code. I have still the page, which is my index for client component slash. And then I have the idea of the post where I'm gonna show you the client component. So in the page, I'm gonna still show my regular rendering, which is this one, right? Just the locale date, that is gonna be the render. And then I'm gonna have a client component, which I will call blog post. So because page cannot be client, right? I need another component to wrap client around and to make it pure client component. I have to create it, of course. So I'm gonna just simply create, to make it client component, use client. For now, it gives you an error because it's still not a full-blown React component, but use client will opt you in for client components, which are not server-side managed.

Something that I will have to pull in, so my import, React, of course. Use as var, which is from this library as var we maintain, just for the classic as var. If you already know what it is, it's just a fetching data API, otherwise, just check it out. It's really, really simple to implement. I will use the use path name because being a client component, I will not have the parameters, right? So the page, it has the parameters, which is the ID. However, from the client component, I will need to read them out from the path, and then I'm gonna use a fetcher, and the fetcher is simply, I wrote it here. Let me figure it out where it is here in lib. The fetcher is simply, is really a copy-paste from the docs, plain simple is just a typical fetcher that is just resolving the promise from the fetcher.

So I'm gonna create my nice blog post, what is gonna return, do it in pieces because then it's a bit easier to check. It's gonna simply return, loading if there is no data, and there is no error and there is data, then the data.title from the blog post, which is the same as before, nothing really changed it there. How am I gonna do it? First things that I'm gonna do is retrieve the path name, which blog post, am I gonna check? Am I gonna check that one, the two? Which one, which one that's gonna come from the ID? And then I'm gonna use as war, which looks like this. I'm gonna use use path name from next directly so I have the path, right? Of the URL. So, Usbr will call your, in this case, the post from the JSON placeholder, so we call your API with the ID, and then there is the possibility to have a refresh interval, seem very similar to ISR, where it's gonna basically fetch constantly the new page. The difference between ISR is that this one is similar to polling. So this is really like, no matter what happens, it's gonna fetch, fetch, fetch. While ISR, it only fetches if somebody goes on that page. It busts the cache, basically. It's more similar to that, rather than fetching, fetching, fetch. This is useful for data that is really in real time, like pure real-time data. Okay, I'm gonna save. I had my production here running, so I have to kill again. And I will also run my production again. It's not super necessary in this case to run production, but if you're used to that. And then I'm gonna see on the page how it's gonna go.

And then you see the loading. You just saw the loading. Actually, what I can do is to, oh, sorry, wrong link. Network, I can throttle. And if I throttle, last time I tried you a very slow one, and I wouldn't suggest it. If I throttle, then you will see the loading because my connection is theoretically very slow, like a 3G connection or 4G in this case. You're gonna actually see how much does it take to pick it up. So it's gonna load, it's gonna take forever. And then at a certain point, hopefully it's gonna fetch my data. Took forever. I would not suggest to do GPRS or stuff like that unless it's really necessary unless it's really jarring, let's say. Something interesting here is that the page is rerendering, but also, if you see the network, I'm gonna wait a little bit. I think it's 5,000 intervals. So every five seconds it's gonna fetch. Just like that. It's really polling the classic one. I use this for a chat. When I was building a chat and then the polling was like every second or something to the database directly to see if there was like any new chat or any new something, like notifications, stuff like that. That was client-side, and how to do the client-side. Dynamic. Is it dynamic the second one? Let me see. Here we go, dynamic. Because then we are gonna go to ISR. What is dynamic data fetching? So when you have a dynamic page in general, that means that you're opting completely, completely out of cache. Which means that every time somebody requests for that page, that page is always gonna come back already re-rendered, already rendered. And it will re-rend every time you request it. I can opt out or in cache in a very, very granular way. I'm gonna give you this link to the beta docs again. It's called route segment config options. When you have config options, or in general, this kind of option for both fetch and the route itself, you can opt in and out from cache and various type of strategies for rendering in a very, very granular way. For example, you can do it only for fetch, but not for the entire route. So potentially you can say, okay, this entire segment or route is gonna have cache, but then the specific fetch in this specific page for this specific component is gonna be no store. So it's gonna be no cache at all, because I know I need it always very, very, very efficient. No, efficient is not the correct word, but let's say from a refreshing standpoint, efficient. Something that's very useful to know. Sometimes you might think, this is gonna be all static, fine. It's gonna be super optimized. But then you notice that you do production build and is dynamic. That's because some functions like cookies, headers are inherently dynamic, so they're gonna opt to in dynamic automatically without you having to explicitly say it. It might be that's the case. What usually you might want to do then is to maybe put those in the leaf, whatever the leaf might be, the farthest away from everything else, so everything gets like nicely wrapped and nicely rerendered correctly. I'm gonna show you how to do that. Dynamic, so same thing. So page is here. ID page, we're gonna do exactly the same. Check the blog post in a dynamic way. The code is really, really similar. I'm gonna paste everything because it's so the same. Wait, paste it properly here. It's so the same of the other pages of the regular server-side pages that I'm gonna just copy-paste exactly the same.

So same thing, same thing, fetch data. We have a fetch data function that's gonna take the parameter which is the ID of the blog post and that one is gonna be sent to the JSON Placeholder. What is different here is that I have options. This cache no store. Those options, they can just be put for each fetch that you have. Consider that you might want to check how the foldbacks are because sometimes they are, you know, they might, for example, a no store and an actual force cache, they might be in enemies, let's say, they're in contrast so they cannot be done together at the same level because otherwise, you know, next we'll not know which one to choose but now I'm just opting out from Static, I'm opting forcibly in Dynamic and if I'm gonna kill my thing and restart my thing over and over to check my production, here we go and I'm gonna, I always refresh, it should reload automatically, I just always fresh when I kill because I'm always afraid of the terminal cache. So if I now check the Posts here, see this production build, so theoretically it should be just static like the server comments maybe but whenever I click it will say 36, 38, 40. So if I inspect it's gonna always be 200 every single time and it's gonna always request the entire thing because I opt it out.

Various things to say, I cannot go over all of these because it's a lot but check it out, check how you can really granularly set your cache options because you can really do wonders. ISR, very, very fancy Next.js feature and not common to have because it's very complex strategy to apply it from a programming perspective, not from an implementation. So now it's gonna be super easy. But in general, yeah, you don't find ISR very often in frameworks which is quite cool to have in Next.js.

So what are we gonna do? Now, Static is the best because Static, if you don't have any data that really needs dynamics, Static is gonna be simply super performant and already generated. Boom, my page is there. Whoa, yay. However, if your page is there and you cannot change it, for some reason maybe you made a typo or the content editor made a typo, that's typical. How do you bust the cache of that page? ISR comes to your help in that regard. ISR, pure ISR is based on time. So there is gonna be a revalidation period. For example, I'm gonna put I think 10 seconds. I wrote 10 seconds. I think also the code is gonna be 10 seconds. And that ISR is gonna every 10 seconds, every request that comes after those 10 seconds is gonna be the one busting the cache basically. So let's say that I wait 10 seconds. One second later, somebody requests that page, cache is busted. So that page is gonna automatically be the fresh one. How to implement it? Also fairly easy also will be the same code because it's easier. I'm gonna just paste the same code that we had before. I'm gonna have a last rendered to show you when is gonna be rendered. I'm gonna have the fetch parameters and that fetch data. Next, revalidate. This is in seconds. Next, revalidate. You just opt in for your fetch data API and every 10 seconds, it's gonna just re-fetch. I have my static params as well. I'll make sure that this is static for the same reason of the other page with the discussion I made with team Newkins to see why didn't opt in. So I already have my statically generated parameters which is the blog post one and the blog post two. Let's test it. And I have to kill. Rebuild all. Every time I have to rebuild because the pages are gonna be back again. So HTML is gonna be rebuilt. And also next you have this nice thing that where you see what is server and what is static and what is pure static and when which ones are already generated and so on. All right, so.

Post, see, 08. I know, sorry. Just probably refresh, sorry. It was now it's 26, 27, 26, 27, 26, 37. See every 10 basically. So 37, 38, 37, 38. At the same time it's gonna be 47. 48, 49. So you see every 10 seconds, I'm gonna request for the page and the cache is gonna be busted and that's gonna be refreshed and revendored and the fetch is gonna be redone. That's why if I move super fast, they're not gonna change because the 10 seconds is not gonna, it's not finished yet, but as soon as the 10 seconds are gone, that page is gonna be, see 16, it's gonna be re-recreated and it's gonna send to me. Now, last, almost last but not least, streaming is fairly easy, but this is a bit longer. I'm gonna try to make it not super slow because, of course, I'm just minding of time. So, OnDemand SR, same of ISR, so you're gonna have statically generated pages, but what if instead of every thought, every 10 seconds, I want this to be, I want the cache to be busted when I decide. It can be anything.

It can be maybe they're old, old pages and you don't want anybody to just go in and bust your cache, or maybe you want to have a re-validation that's quite long, two days, but then whenever you change a post in a CMS, for example, in a headless CMS, your content editor, maybe they want to immediately like, oh, wait, let's republish immediately because the breaking news are over or the Black Friday's over right now, now, so I need to immediately bust the cache.

A little bit more work, but it's not too much really. It's just a couple of things that we need to know. What I'm going to use here is this really, really cute mock API. So I'm going to paste the code, sorry, the link here. So I just discovered it like three, four days ago. So you can, you have to subscribe, to subscribe for free. It's free for now. At least for basic, basic hobby things. They give you a link, an HPS link, and then you create a resource, which is basically your endpoint. And I created my posts here, and you can like add them with the fake data that they create. And if you check the data, you can actually change it. So you can change it at an update. And this is perfect to try on-demand SR if it works or not.

Okay, how to do that? I'm going to close here, close this one. So same, same, we're going to always have the posts and so on. However, now what is going to be different is going to be that, let me paste to say the same things that is not going to be different. So it's the things that are not going to be different is going to be like the data.title, the fetch parameters, right? We did parameters as the blog post and basically the fetch data which uses a fetch to actually retrieve the blog post, right? First things first, how am I going to call my environment? My environment, I use process.env. So basically an environment variable to have my link. So the link that I showed you, the one that's created just for you, that's basically what is going to be there for having your post. Slash post is how I called, I can't remember, this one, post, right? So when you create a new resource, it's going to ask you what is the name of the resource which is basically the name of your endpoint and I call it post. So slash post is going to be the endpoint. What is nice, let me see if it shows you here. Yeah, what is nice is going to be that when you have post ID, for example, it's automatically generated and it's going to ask for that post. So you don't have to do anything. And then I'm going to just write the TP call. The TP call is going to be, okay, return the data so it has like all the stuff, all the jazz, and then just for the sake of being safe, opt-in for static because again, for what concerns the beta might be that some things are still not opting in even if you want to. What else would I need to do? So in this case, the page is just created. So it is a static page. Nothing fancy. But if I want to bust the cache, I need something else. Namely, it's a webhook. Usually the webhooks are in API from the server side of Next. And I still don't have it. So I'm going to have to create a new folder. And the folder is going to be pages. Pages is the one from basically the other version, right? From Nexus 12. API is going to still be in pages. So API is just your server side, the API, the server, the backend of the frontend, let's say it like that. And in my API from pages, so for now, API is still there. Maybe it's going to change later on. But for now, everything you have in pages API is going to stay there. It's not going to change. In API, I will create backend, hello. Sometimes my edit hides itself. It will create a route. The route would be revalidate, it's an API route. So it's going to pick up these names. So it's going to be slash API slash revalidate. And there I'm going to just copy paste the typical, typical revalidation code.

Which does the following. Checks the revalidation token. You always need a revalidation token. I have it in my process.env. And I have it in my local.env. So it's here. I call it Alice because it's easier. So my revalidation code would be Alice. So if I say, I will show you. But if I say API slash revalidate, and then a question mark, and then in my query parameters. So I'm going to be secret is Alice. This is going to check if my process environment validation token has the same. And then if not, it's going to for an error, otherwise it's gonna bust the cache for that single ID that I'm also going to send through query parameters. So I'm going to send from query parameters both. My secret, and also the idea of the post that I'm going to bust. And I'm going to see that the other post still going to be the old one. That's it. I'm going to also now show you how does it work? So how these would just bust the cache. Same same, same old, same old. Kill all. We are on incremental, right? So changing, nothing happens, nothing happens. Refresh, nothing happens. The date is always going to be the same. Same, same, same, right? I'm going to go and change my API. New, updated. I'm going to go back, refresh. Nothing happens. Nothing happens. Nothing happens. Nothing happens because it's cached. Well, what do I want? Is to revalidate. Then what I'm going to do is do local host and then API. Here we go. Revalidate secret aliche ID one. Now ID one has the cache busted. Gonna go back, post two. Refresh, refresh, refresh. Nothing happens. Ta da da. Post one. Just revalidated. On demand because I called this API. And this API can be called from anywhere, right? It's just a call API. I just called it from the browser. And this one will just stay cached until I don't call the same API on the two.

Okay, last but not least, so I let you go. Streaming with suspense. What does it do? For this one I had to opt in for dynamic because otherwise, of course, when you are on the server side, it's gonna just render everything and that's gonna just push. They already rendered data and then have it static by default. So I had to like opt in for dynamic to actually show you how does it work.

Streaming means that each piece of this UI that is gonna be wrapped around the suspense boundary from React is gonna just stream independently, meaning that your page is not gonna be blocked completely for the entire HTML. It's going to be piece-by-piece rendered. So if one API takes forever, it doesn't have to block everything else, right? You maybe want the upper funnel to be immediate. And then it doesn't matter if, I don't know, any lower funnel is gonna be problematic or be slower for some reason. So you want pages, part of the pages that are immediately interactive, up to cart or the first page of a multi-paged list of products, stuff like that.

How do you do that? So we are gonna do the posts now. So we're gonna have multiple posts. Streaming. So now it's a little bit different. So I have streaming slash posts. And then here, I'm gonna stream multiple posts at the same time. Within the page, I'm gonna throw tons of errors, of course, because I have some things missing right now, but bear with me. Within the page, I'm gonna do this. One suspense for the first post and another suspense separately for the second post. I created a delay because that delay will actually show the rendering, the fact that, hey, I'm streaming this, I'm waiting for this, and this one will be three seconds earlier than the other one. And I'm already gonna be able to interact with it without having to wait for the second one. What I will need now, I'm gonna just, new file, I call it PostScale. Don't be a six, this is mere UI, so I'm not not gonna explain it, it's really, really a basic UI. I stole it from the app playground, as I said, like the rest of some of the code from our own examples for the app playground. I'm gonna paste it as soon as I finish this one. And then I'm gonna have a button, so another very UI thing, so you don't need to have too much of, all right, I'm writing in the nothing. Very, very quickly, is a client button. So use client, react. I have a state, so it is pure client, right, because set state is only for the client, pure state, and this is just gonna be clicking the counts basically, every time I click is counting, this is per post. So I'm gonna show you that I can actually click on this one much before the other post is being retrieved. And then last, but absolutely not least, is gonna be the actual post, which is the important one, because it's the one where I have all the nice things. So this post is gonna be very similar to the rest. Fetching data, similar. I have a button, I have the locale time string as before, and I still have to fetch the data. And fetching the data will be exactly the same, nothing changes here, same thing code. The only difference is that I added this little piece to fake the delay, because otherwise I wouldn't have any delay in localhost, right? So I'm faking the delay. The delay is personalized per post. So the first post was three seconds, the other one would be six seconds. Done. So what it's gonna do is fetching delay, the two posts are gonna simply come here, right, go in the index which is the page, start streaming the first one, start streaming the second one. But the first one's gonna come much earlier than the other one, because of my fake delay. And now I'm gonna show you. I don't need necessarily now the production bit, so I can just use Yarn dev, the classic Yarn dev, because it's gonna be dynamic and it's fine. Let's see if the post work, ta-da. Now it's working and you can see the first one, I can click, click, click, click, doesn't really matter because the second one came in just a bit later and it won't block the entire post page. We're a little bit out of time, that was it. I'm gonna post, post, push this code so in the GitHub repository so you can actually see it live. If you have any question, access the preview comments, I hope it was useful. Let me know if anything.