So we did now learn
about a lot of different cache settings,
and we learned how those settings can be used
to control the data cache.
Now, besides that data cache,
NextJS also has a full route cache,
and that's actually the kind of cache
we saw in action in this application before.
Because that full route cache is actually already created
and initialized at build time,
which simply means that if I stop that development server
and I build this NextJS application for production
by running npm run build, NextJS goes ahead
and pre-renders all the pages of this application,
unless they're dynamic pages with a dynamic parameter,
because there, by default,
it doesn't know all the possible dynamic parameter values,
but it pre-renders all the pages it's able to pre-render.
You also see that here, that all those pages marked
with a dot were pre-rendered,
so the messages page, for example,
was pre-rendered, as you can tell,
and the implication of that is
that when we start the production server with npm start,
it will actually be those pre-rendered pages
that we see out of the box, and those pages
are actually cached by NextJS, you could say.
Therefore, now with that production server up and running,
if I clear and restart my backend,
we will actually see no log message at all here
when I reload that messages page,
and we see no log message here at all
because that page was pre-rendered at build time
and it's cached, and it's now always
that pre-rendered cached page that's being served here,
no matter how often I reload or navigate away and come back.
It's always that pre-rendered page.
Hence, we got no logs here on that backend server.
Now, that's, of course, fine,
as long as the data here doesn't change,
and in this dummy application with that dummy backend,
that's the case because the data served
from that dummy backend does never change,
but we saw before in the previous section
where we learned about data mutations with NextJS
that this can be a problem if we have data that does change,
because due to that pre-rendered cached page,
NextJS never re-renders and updates that page,
And that's another thing that will be controlled
by setting one of these cache settings here.
For example, if I set force dynamic to this entire file
to make sure that there is no data caching,
I automatically also disable the full route cache
for this page, and I make sure that,
instead of pre-rendering and caching this page,
NextJS will always re-render that page
whenever a request is sent to it,
which ensures that we're always fetching fresh data,
and that's why, when I enable this dynamic constant
and set it to force dynamic here, and I then save that file,
and I then rebuild my project to rebuild it for production,
now, this messages route has a different symbol here,
which means that it's a dynamic page now,
which is server-rendered on demand,
as you can tell down here.
And indeed, that's what we can see
when we start the production server with npm start.
Now, if we take a look at this backend log,
if I reload this page a couple of times,
I see a bunch of logs here,
because now it's not just the data cache that's cleared,
but also that full route cache,
and we make sure that it's not some pre-rendered page
that's reused over and over again.
Of course, we don't have to use this setting
to make sure that we see updated data.
A different approach would be to revalidate the cache
of a specific page on demand
with the revalidate path function we already used
in the previous section, and that's now a function
which we'll revisit in the next lecture
before we then thereafter will take a look
at how we can manage caching
if we're not sending a request to a separate backend,
but instead to some other data source,
like a database we manage in the NextJS application.