So you did now learn about this request
memoization feature.
Now what might be weird though is that
after this one initial request, if I reload
this page or if I go to a different page
and come back, no further requests are
sent to the backend.
As you can tell by the fact that no new
logs are being added here.
At least that will be the case if you are
using Next.js version 14.
And as mentioned before, you can check
your package.json file to find out which
version you are using.
If you are on Next.js version 15 or higher,
you actually will see multiple requests
here because the default caching
behavior of fetch requests, so of requests
sent with the fetch function as we are
doing it here, has been changed with
Next.js version 15.
Now I'll get back to that and for the
moment, I'll assume you are using
Next.js version 14 or older, and I'll walk
you through the behavior there before
I'll then get back to the Next.js version 15
behavior.
No matter how often I reload this page
or navigate back and forth, no new logs
are added.
And that's the case because of this data
cache that's also provided by Next.js.
Because what Next.js does when using
the fetch function for fetching data from
a backend is it will store the response
data fetched from there in some
internally managed server-side cache
and it will keep reusing that data forever
until you tell it to not do that anymore.
Now, how can you tell Next.js to not
reuse that data anymore?
Well, you could call revalidatePath as you
learned before in this course after you
changed some data, but here I'm not
actually changing the data on that
dummy backend, so I won't do that here,
but you could do that as you learned it in
the previous section already because
that would tell Next.js that the data for a
specific path, so the data used on a
specific page, did change and it would
throw away the respective data cache.
But alternatively, you can also configure
this fetch function because you can add
a configuration object to it and on that
configuration object, you can set various
settings.
For example, the cache setting.
You can do that when using fetch in the
browser side and you can also do that
when using fetch on the server side.
Now, what's important to understand
here is that on the server side, Next.js is
actually overriding the default built-in
function that is provided by modern
Node.js and it essentially does that so
that it can find out what cache settings
you set up here because that will then
change the behavior of the Next.js
cache.
And here, you get various options,
though the two important options when
using Next.js are force cache, which is
the default with Next.js version 14, which
gives you the most aggressive caching
behavior as this setting, force cache, will
ensure that the response yielded for this
fetch request will be cached and reused
across requests until you give Next.js an
indication that the fetched data has
changed.
So that's the aggressive default behavior
you get with Next.js 14.
The other important setting is no store,
which is the default with Next.js 15 or
higher, which is why you see multiple
requests hitting the backend if you are
using Next.js 15 or later because with no
store, Next.js will not store the response
yielded by the fetch request.
It will not cache it.
So you don't have that aggressive
caching behavior there.
Of course, you could switch to force
cache if you wanted, if you want more
efficiency, if you want more caching, but
the default with Next.js 15 is no store.
The other options, at least at the point of
time where I'm recording this, are not
important for the Next.js cache
management.
But cache no store will tell Next.js that
for this fetch request in this place, so not
in other places where the same request
is sent, but instead just in this place, the
data should not be cached.
Instead, now with this setting, I'm
forcing Next.js to always send a new
request and use the response data of
that request instead of caching and
reusing the data.
And therefore, if I save that, I can already
see that some new logs were added
here.
The number may vary for you, but if I
reload the messages app a couple of
times, you see more new log messages
were added.
So that's this no store setting.
An alternative way of getting Next.js to
revalidate the data is to again configure
the request, but now not with the cache
setting, but instead with the special next
setting, which is available on that fetch
API if using it in a Next.js application,
because as I mentioned, Next.js extends
that fetch function and adds some new
settings to it.
For example, the next setting, which
wants an object, which allows me to set
a revalidate setting.
And here I can define a number, which
will be the number of seconds Next.js
should continue reusing the cache data
until it will revalidate and throw away
the cache.
So if I set this to five, I'm telling Next.js
that the cached data should be reused
for five seconds.
And then thereafter, it should throw
away the cached data and send a new
request and get some new data.
And within that five second timeframe, if
any requests to this page would be sent,
it would instead not send extra requests
to a backend, but reuse the cached data.
We can see that if I clear the backend
console again and restart the backend
server.
If I reload this page, I got one request
here now, but now if I reload it a couple
of times again, you see only one more
request was added.
And I did press that refresh button, that
refresh shortcut multiple times.
But most of those extra requests I sent
to this Next.js page were within that five
second timeframe, and hence only one
new request was sent.
And of course that five second
timeframe will then restart every time
some fresh data has been fetched and
used.
So setting this revalidate setting is an
elegant way of ensuring that you get
some caching advantages, but you're
not caching data forever.