Check out a free preview of the full Headless CMSs with Next.js course

The "Caching" Lesson is part of the full, Headless CMSs with Next.js course featured in this preview video. Here's what you'd learn in this lesson:

Scott explains how caching works in Next.js and demonstrates two ways to break the cache. The first method involves setting a revalidation interval using the `revalidate` property in the `fetch` function. The second method involves creating a route in the API folder and setting up a webhook on Contentful to trigger a revalidation of specific cache tags. This allows for the display of new content without rebuilding the entire site.


Transcript from the "Caching" Lesson

>> Scott Moss: Okay, so the other thing is caching. Okay, so if I go publish a change and then I wanna see that change reflected in production immediately, I won't because Next.js is going to cache it by default. So, you need a way to break that cache, there are basically two ways to do do it..

One way we can't really demonstrate here without setting up a tunnel. I looked there was no easy way to set up a free tunnel that wasn't gonna have people doing things that they probably don't know how to do, so we're not gonna do the tunnel. But the other way we can do and that's just gonna be setting a revalidation interval on which we want at most the content to revalidate it.

And we could do that because Next.js hijacked, so if you go to our fetch file, Next.js hijacked the fetch function and they have a new property here called next. And I can say revalidate like this, or I'm sorry, tags like this.
>> Scott Moss: And you can pass in an array of tags which are basically, you can think of them as like cache keys in which this query is going to be cached, so you can then revalidate later, right?

So for here that just means I need to add in another property appear in this argument. So I'll say, I'll say tags and I'll make that an array of strings like that. Tags, there we go, so you can pass in some tags. That'll go here, and then for revalidate you can put in any number of seconds, not milliseconds, but seconds.

How long you want before this fetch call to be re reran, basically. So this will allow us, so basically if you're like, I want, you can think of it as polling, that's the best way I can describe of it. It's like, okay, every 25 seconds run this function again.

And if there's been new data, new content that was published in those 25 seconds, that's what's gonna show up on the screen. When you go back to it, it's not just gonna pop up. You have to, it's when you render the page again, it'll show.
>> Scott Moss: Right, so let's check it out, I'll put one for 10 seconds.

So I'll say revalidate for 10 seconds for every single one of these, right? And then just to show you how this works, I'll go into the CMS, beta is live, I'll publish that. I think that's what was already there, I'm published. I'm just gonna say, new change, before I hit that, let's just go back to the site.

Let's just clear the cache, refresh, make sure it still says data's live, no cache, okay, we're good. All right, now if I go back here, I publish these changes.
>> Scott Moss: Cool, and then if I go in.
>> Scott Moss: Go back here. How long did I put the thing on for one second, 10 seconds, okay.

So 10 seconds, let's wait for a little bit. So now I don't have to do a before what I would have to have done to see the latest on this publish was to do a hard refresh. I have to do a command shift R just to see the changes, but now after 10 seconds, if I just do a command R, it's 10 seconds hasn't passed yet, there it is.

There's a new change, right? So, it revalidated that after 10 seconds, so when the next person goes to that site, after 10 seconds you'll see it. Whereas before, it's basically cached indefinitely, and the only way to see it is like, if, in this case on development, do a hard refresh
>> Scott Moss: On production, you just won't see it [LAUGH] because it'd be a static site, it'd be a static page.

It's hitting the server in development, but in production, you just wouldn't see it. So how do you get around it in production? Great question, so in production, the way you get around it is you would set up another route. So you notice we have this tax here right?

So what I can do, let's say I go to our.
>> Scott Moss: I go to our hero fetch here, and I wanna pass in some tags. So I wanna say, tags, this is called hero. Okay? So I'm gonna say this is called hero here, those are my tags, right?

Then what I would do is I would make a route in our API folder here and I would call it whatever you want. Call it revalidate, whatever you want. All it's gonna do, it's just gonna say, revalidate tag and it's gonna pass this, you're gonna pass in the name of the tag you want to revalidate.

In this case, I would say hero. You are then going to go assign that route to a webhook or Contentful when something gets published. So you can say, hey, when this new thing gets published on a new published event, here's the webhook I want you to hit. That's gonna be a route that you just made that revalidated the tags called hero, which will then in production do exactly what we just saw with the 10 seconds.

So the next time you go to the page, it'll show the new hero. And that way you can show new content without having to rebuild the site.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now