1
00:00:00,000 --> 00:00:02,000
So you did now learn about this request

2
00:00:02,000 --> 00:00:03,000
memoization feature.

3
00:00:04,000 --> 00:00:07,000
Now what might be weird though is that

4
00:00:07,000 --> 00:00:10,000
after this one initial request, if I reload

5
00:00:10,000 --> 00:00:12,000
this page or if I go to a different page

6
00:00:12,000 --> 00:00:16,000
and come back, no further requests are

7
00:00:16,000 --> 00:00:17,000
sent to the backend.

8
00:00:17,000 --> 00:00:20,000
As you can tell by the fact that no new

9
00:00:20,000 --> 00:00:22,000
logs are being added here.

10
00:00:22,000 --> 00:00:25,000
At least that will be the case if you are

11
00:00:25,000 --> 00:00:28,000
using Next.js version 14.

12
00:00:28,000 --> 00:00:30,000
And as mentioned before, you can check

13
00:00:30,000 --> 00:00:32,000
your package.json file to find out which

14
00:00:32,000 --> 00:00:34,000
version you are using.

15
00:00:34,000 --> 00:00:38,000
If you are on Next.js version 15 or higher,

16
00:00:38,000 --> 00:00:42,000
you actually will see multiple requests

17
00:00:42,000 --> 00:00:45,000
here because the default caching

18
00:00:45,000 --> 00:00:48,000
behavior of fetch requests, so of requests

19
00:00:48,000 --> 00:00:50,000
sent with the fetch function as we are

20
00:00:50,000 --> 00:00:52,000
doing it here, has been changed with

21
00:00:52,000 --> 00:00:54,000
Next.js version 15.

22
00:00:55,000 --> 00:00:56,000
Now I'll get back to that and for the

23
00:00:56,000 --> 00:00:58,000
moment, I'll assume you are using

24
00:00:58,000 --> 00:01:01,000
Next.js version 14 or older, and I'll walk

25
00:01:01,000 --> 00:01:03,000
you through the behavior there before

26
00:01:03,000 --> 00:01:04,000
I'll then get back to the Next.js version 15

27
00:01:04,000 --> 00:01:05,000
behavior.

28
00:01:06,000 --> 00:01:09,000
No matter how often I reload this page

29
00:01:09,000 --> 00:01:12,000
or navigate back and forth, no new logs

30
00:01:12,000 --> 00:01:13,000
are added.

31
00:01:14,000 --> 00:01:17,000
And that's the case because of this data

32
00:01:17,000 --> 00:01:20,000
cache that's also provided by Next.js.

33
00:01:21,000 --> 00:01:24,000
Because what Next.js does when using

34
00:01:24,000 --> 00:01:27,000
the fetch function for fetching data from

35
00:01:27,000 --> 00:01:32,000
a backend is it will store the response

36
00:01:32,000 --> 00:01:35,000
data fetched from there in some

37
00:01:35,000 --> 00:01:38,000
internally managed server-side cache

38
00:01:38,000 --> 00:01:41,000
and it will keep reusing that data forever

39
00:01:41,000 --> 00:01:45,000
until you tell it to not do that anymore.

40
00:01:46,000 --> 00:01:49,000
Now, how can you tell Next.js to not

41
00:01:49,000 --> 00:01:50,000
reuse that data anymore?

42
00:01:51,000 --> 00:01:57,000
Well, you could call revalidatePath as you

43
00:01:57,000 --> 00:01:59,000
learned before in this course after you

44
00:01:59,000 --> 00:02:02,000
changed some data, but here I'm not

45
00:02:02,000 --> 00:02:03,000
actually changing the data on that

46
00:02:03,000 --> 00:02:06,000
dummy backend, so I won't do that here,

47
00:02:06,000 --> 00:02:08,000
but you could do that as you learned it in

48
00:02:08,000 --> 00:02:10,000
the previous section already because

49
00:02:10,000 --> 00:02:14,000
that would tell Next.js that the data for a

50
00:02:14,000 --> 00:02:16,000
specific path, so the data used on a

51
00:02:16,000 --> 00:02:19,000
specific page, did change and it would

52
00:02:19,000 --> 00:02:21,000
throw away the respective data cache.

53
00:02:23,000 --> 00:02:26,000
But alternatively, you can also configure

54
00:02:26,000 --> 00:02:31,000
this fetch function because you can add

55
00:02:31,000 --> 00:02:34,000
a configuration object to it and on that

56
00:02:34,000 --> 00:02:37,000
configuration object, you can set various

57
00:02:37,000 --> 00:02:37,000
settings.

58
00:02:38,000 --> 00:02:40,000
For example, the cache setting.

59
00:02:41,000 --> 00:02:43,000
You can do that when using fetch in the

60
00:02:43,000 --> 00:02:45,000
browser side and you can also do that

61
00:02:45,000 --> 00:02:47,000
when using fetch on the server side.

62
00:02:48,000 --> 00:02:50,000
Now, what's important to understand

63
00:02:50,000 --> 00:02:53,000
here is that on the server side, Next.js is

64
00:02:53,000 --> 00:02:57,000
actually overriding the default built-in

65
00:02:57,000 --> 00:03:00,000
function that is provided by modern

66
00:03:00,000 --> 00:03:03,000
Node.js and it essentially does that so

67
00:03:03,000 --> 00:03:05,000
that it can find out what cache settings

68
00:03:05,000 --> 00:03:08,000
you set up here because that will then

69
00:03:08,000 --> 00:03:10,000
change the behavior of the Next.js

70
00:03:10,000 --> 00:03:11,000
cache.

71
00:03:12,000 --> 00:03:14,000
And here, you get various options,

72
00:03:14,000 --> 00:03:17,000
though the two important options when

73
00:03:17,000 --> 00:03:20,000
using Next.js are force cache, which is

74
00:03:20,000 --> 00:03:23,000
the default with Next.js version 14, which

75
00:03:23,000 --> 00:03:25,000
gives you the most aggressive caching

76
00:03:25,000 --> 00:03:30,000
behavior as this setting, force cache, will

77
00:03:30,000 --> 00:03:34,000
ensure that the response yielded for this

78
00:03:34,000 --> 00:03:37,000
fetch request will be cached and reused

79
00:03:37,000 --> 00:03:41,000
across requests until you give Next.js an

80
00:03:41,000 --> 00:03:44,000
indication that the fetched data has

81
00:03:44,000 --> 00:03:45,000
changed.

82
00:03:45,000 --> 00:03:47,000
So that's the aggressive default behavior

83
00:03:47,000 --> 00:03:49,000
you get with Next.js 14.

84
00:03:50,000 --> 00:03:54,000
The other important setting is no store,

85
00:03:54,000 --> 00:03:57,000
which is the default with Next.js 15 or

86
00:03:57,000 --> 00:04:00,000
higher, which is why you see multiple

87
00:04:00,000 --> 00:04:03,000
requests hitting the backend if you are

88
00:04:03,000 --> 00:04:07,000
using Next.js 15 or later because with no

89
00:04:07,000 --> 00:04:11,000
store, Next.js will not store the response

90
00:04:11,000 --> 00:04:12,000
yielded by the fetch request.

91
00:04:12,000 --> 00:04:14,000
It will not cache it.

92
00:04:14,000 --> 00:04:16,000
So you don't have that aggressive

93
00:04:16,000 --> 00:04:18,000
caching behavior there.

94
00:04:18,000 --> 00:04:20,000
Of course, you could switch to force

95
00:04:20,000 --> 00:04:23,000
cache if you wanted, if you want more

96
00:04:23,000 --> 00:04:27,000
efficiency, if you want more caching, but

97
00:04:27,000 --> 00:04:30,000
the default with Next.js 15 is no store.

98
00:04:31,000 --> 00:04:32,000
The other options, at least at the point of

99
00:04:32,000 --> 00:04:36,000
time where I'm recording this, are not

100
00:04:36,000 --> 00:04:38,000
important for the Next.js cache

101
00:04:38,000 --> 00:04:38,000
management.

102
00:04:39,000 --> 00:04:43,000
But cache no store will tell Next.js that

103
00:04:43,000 --> 00:04:48,000
for this fetch request in this place, so not

104
00:04:48,000 --> 00:04:50,000
in other places where the same request

105
00:04:50,000 --> 00:04:53,000
is sent, but instead just in this place, the

106
00:04:53,000 --> 00:04:55,000
data should not be cached.

107
00:04:55,000 --> 00:04:58,000
Instead, now with this setting, I'm

108
00:04:58,000 --> 00:05:02,000
forcing Next.js to always send a new

109
00:05:02,000 --> 00:05:04,000
request and use the response data of

110
00:05:04,000 --> 00:05:06,000
that request instead of caching and

111
00:05:06,000 --> 00:05:07,000
reusing the data.

112
00:05:09,000 --> 00:05:11,000
And therefore, if I save that, I can already

113
00:05:11,000 --> 00:05:13,000
see that some new logs were added

114
00:05:13,000 --> 00:05:13,000
here.

115
00:05:13,000 --> 00:05:16,000
The number may vary for you, but if I

116
00:05:16,000 --> 00:05:17,000
reload the messages app a couple of

117
00:05:17,000 --> 00:05:20,000
times, you see more new log messages

118
00:05:20,000 --> 00:05:21,000
were added.

119
00:05:21,000 --> 00:05:24,000
So that's this no store setting.

120
00:05:24,000 --> 00:05:27,000
An alternative way of getting Next.js to

121
00:05:27,000 --> 00:05:31,000
revalidate the data is to again configure

122
00:05:31,000 --> 00:05:33,000
the request, but now not with the cache

123
00:05:33,000 --> 00:05:35,000
setting, but instead with the special next

124
00:05:35,000 --> 00:05:39,000
setting, which is available on that fetch

125
00:05:39,000 --> 00:05:42,000
API if using it in a Next.js application,

126
00:05:42,000 --> 00:05:45,000
because as I mentioned, Next.js extends

127
00:05:45,000 --> 00:05:48,000
that fetch function and adds some new

128
00:05:48,000 --> 00:05:49,000
settings to it.

129
00:05:49,000 --> 00:05:51,000
For example, the next setting, which

130
00:05:51,000 --> 00:05:54,000
wants an object, which allows me to set

131
00:05:54,000 --> 00:05:55,000
a revalidate setting.

132
00:05:57,000 --> 00:06:00,000
And here I can define a number, which

133
00:06:00,000 --> 00:06:03,000
will be the number of seconds Next.js

134
00:06:03,000 --> 00:06:06,000
should continue reusing the cache data

135
00:06:06,000 --> 00:06:09,000
until it will revalidate and throw away

136
00:06:09,000 --> 00:06:09,000
the cache.

137
00:06:10,000 --> 00:06:13,000
So if I set this to five, I'm telling Next.js

138
00:06:13,000 --> 00:06:16,000
that the cached data should be reused

139
00:06:16,000 --> 00:06:17,000
for five seconds.

140
00:06:18,000 --> 00:06:20,000
And then thereafter, it should throw

141
00:06:20,000 --> 00:06:23,000
away the cached data and send a new

142
00:06:23,000 --> 00:06:24,000
request and get some new data.

143
00:06:25,000 --> 00:06:29,000
And within that five second timeframe, if

144
00:06:29,000 --> 00:06:31,000
any requests to this page would be sent,

145
00:06:32,000 --> 00:06:35,000
it would instead not send extra requests

146
00:06:35,000 --> 00:06:37,000
to a backend, but reuse the cached data.

147
00:06:38,000 --> 00:06:41,000
We can see that if I clear the backend

148
00:06:41,000 --> 00:06:43,000
console again and restart the backend

149
00:06:43,000 --> 00:06:44,000
server.

150
00:06:45,000 --> 00:06:48,000
If I reload this page, I got one request

151
00:06:48,000 --> 00:06:51,000
here now, but now if I reload it a couple

152
00:06:51,000 --> 00:06:54,000
of times again, you see only one more

153
00:06:54,000 --> 00:06:56,000
request was added.

154
00:06:56,000 --> 00:06:59,000
And I did press that refresh button, that

155
00:06:59,000 --> 00:07:01,000
refresh shortcut multiple times.

156
00:07:01,000 --> 00:07:04,000
But most of those extra requests I sent

157
00:07:04,000 --> 00:07:07,000
to this Next.js page were within that five

158
00:07:07,000 --> 00:07:09,000
second timeframe, and hence only one

159
00:07:09,000 --> 00:07:10,000
new request was sent.

160
00:07:11,000 --> 00:07:13,000
And of course that five second

161
00:07:13,000 --> 00:07:16,000
timeframe will then restart every time

162
00:07:16,000 --> 00:07:18,000
some fresh data has been fetched and

163
00:07:18,000 --> 00:07:18,000
used.

164
00:07:19,000 --> 00:07:22,000
So setting this revalidate setting is an

165
00:07:22,000 --> 00:07:24,000
elegant way of ensuring that you get

166
00:07:24,000 --> 00:07:27,000
some caching advantages, but you're

167
00:07:27,000 --> 00:07:28,000
not caching data forever.