Intermediate Next.js

Cache & Revalidation Strategies

Scott Moss

Scott Moss

Superfilter AI
Intermediate Next.js

Check out a free preview of the full Intermediate Next.js course

The "Cache & Revalidation Strategies" Lesson is part of the full, Intermediate Next.js course featured in this preview video. Here's what you'd learn in this lesson:

Scott discusses additional strategies for revalidating cache manually and some of the ways Next.js will revalidate the cache for you.


Transcript from the "Cache & Revalidation Strategies" Lesson

>> Scott Moss: We talked about revalidating the cache on the initial server queries or the server actions that we did on the react server components for our pages and slots. Now I just wanna kind of cover all the different ways you can revalidate, and some of the other ways in which your data might automatically be revalidated.

So just wanna kind of cover some of that. So one of the first ones is time-based revalidation. Time-based revalidation occurs automatically after a specific time interval. So there's a way you can do that, I don't really use fetch a lot on the server side, but if you look at the next ASDOCS, they use it a lot.

You can tell they've obviously patched fetch to be able to do things like this, but you can give it a time if you're using the fetch, in which you want this to revalidate. Otherwise, it'll always when you call it again within that time, it'll just be cached. So that's something you can do, I've just never had good experience with time based caching for a front-end app.

I feel like that's better for something network layer, something that you can actually use a TTL on and do something on a network level, maybe like Redis, but I don't know. I just never figure out, well, what time do I put here? How often should this be, because it's like the unpredictable nature of a user, who knows how long they're gonna be somewhere?

So I guess it's like a combination of give it a validate time, but then also at the same time, you revalidate it yourself. So maybe it's a combination, but by itself, I feel like it's not too useful, what number do you know what to put here? You can also do this, so that's like if you're using fetch on the server side, but if you're just like in our case, the pages, well, not our case cuz we're using cookies.

But in places where the cookies were not being used, you could say, cool, you can export a variable called revalidate in a page or a layout, you can give it a time in seconds, and that's how long that page will be re-validated. If you wanted to do that, but again, this doesn't really matter to us because all of our pages and slots use cookies.

So it's never cached until we cached it with the memoize function, so that's how you do that. Again, I will probably never do that, I don't know when I would do that, or why, or what would that look like. If someone's on your app, they're just sitting on the screen and then it re-validated and like 30 things is popped up like a jumpscare, I don't know, that'd be kind of weird.

It's like I want more control when that happens, but maybe I'm thinking about Iran.
>> Scott Moss: A couple other things here, so on demand revalidation, this is what we did. So, you could do a revalidate path, which is something we didn't have to do, again, because really none of our pages were cached because they had cookies.

If they didn't use something on the header, a revalidate path is pretty much you can think of it as every page gets its own tag, its tag is its URL. So you can say revalidate this path, so this whole page revalidate it and it'll get cleaned out. We use tag base, which is like exactly what it sounds like, we give it a tag, we can revalidate it when we call revalidate with that tag.

So you can also do that with fetch, again, I rarely use fetch inside of server components, maybe I just haven't hit that use case yet. One of the things I have done though, is use third party APIs to have STKs, for instance stripe or something like that on the service side.

And obviously those things are making http calls, but you don't have access to, or even know if they're using fetch. So the caching strategy to that is, I don't know, I don't really know how that works. Bt at the same time, do I want that to be cached?

So there's still a lot to think about on the server side in my opinion, and I don't think a lot of people actually do fetch on the server side like this, though they do. I'm writing code wrong, I don't really do a lot of server side fetch calls, I guess.

If there's an API that I need to hit on the server side is probably through some SDK that I installed most likely. It's like very rare where I'll do that if that's the case busted or something like that. But I guess if you like microservices and we're talking across your microservices, I can see that.

So maybe it's useful there, I don't have microservices. Yep, V Valley tag, that's what we did here, so we know about that one, this one's really nice. So basically, if the revalidation fails, when you call revalidation tag or the time expires or revalidation path and the revalidation fails, it'll just serve the last one that was good.

So it won't be in a broken state, that's actually quite useful. So, opting out of some of the data cachings or here's some of the things you can do on the fetch. You can say no store like this, or you can say re-validate to zero, that works as well.

Route handler requests, we don't have any route handlers in this course. There really isn't much more advanced stuff to them other than what I covered in the intro, so I didn't feel the need to cover it. But if you use headers or cookies, that route handler won't be cached because those things are dynamic, anything attached to the request object, it won't be cached.

If you're not using those things, and you just wanna force that route handler to be not cached, you can say dynamic equals force and you can export that. I guess like do you recommend using no cache at all or would you recommend to try to always cache? The way that I think about it is I'm shooting to always get cache, but I wanna be in control of the cache.

I don't like the automatic caching, and I don't like if you use this function anywhere, cuz the problem is it's not obvious, right? Sometimes you'll be in a react server component that uses a function, that uses a function, that uses a function, that uses a function, and that function uses a cookie.

So then it's like, how do you know if this is caching or not? That's where it starts to get complicated. So for me, I would just rather turn off the automatic caching, and then opt into caching manually by doing the thing that I showed you guys how to do, and then just do, on demand revalidation by calling revalidate tag.

That way at least I know what I cache and when I revalidate it, versus it depends on the time or the dev environment or production or what method you use, to me that's just so complicated to keep track of. So you definitely want cache, but you want it to be predictable.

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