1
00:00:00,000 --> 00:00:02,000
So at this point,

2
00:00:02,000 --> 00:00:05,000
we've seen in detail

3
00:00:05,000 --> 00:00:06,000
how we can manage caching

4
00:00:06,000 --> 00:00:10,000
when sending requests to external APIs.

5
00:00:10,000 --> 00:00:12,000
But of course, in the previous sections,

6
00:00:12,000 --> 00:00:14,000
we also learned that often

7
00:00:14,000 --> 00:00:16,000
you might not need to communicate

8
00:00:16,000 --> 00:00:18,000
with external APIs.

9
00:00:18,000 --> 00:00:20,000
You might not be using this fetch function

10
00:00:21,000 --> 00:00:24,000
and therefore, in this and the next lectures,

11
00:00:24,000 --> 00:00:27,000
I'll show you how you can still take advantage of caching

12
00:00:27,000 --> 00:00:31,000
and control caching when using another data source

13
00:00:31,000 --> 00:00:34,000
like a database to which you directly reach out

14
00:00:34,000 --> 00:00:36,000
from inside your next application.

15
00:00:37,000 --> 00:00:38,000
Therefore, to get started,

16
00:00:38,000 --> 00:00:42,000
I'll comment out this code where I sent this fetch request

17
00:00:43,000 --> 00:00:48,000
and instead, I will call getMessages here

18
00:00:48,000 --> 00:00:50,000
in my MessagesPage

19
00:00:50,000 --> 00:00:53,000
and getMessages is a function from the lib folder.

20
00:00:53,000 --> 00:00:56,000
So this folder and this file in there.

21
00:00:56,000 --> 00:01:01,000
And in there, I'm managing a simple SQLite database.

22
00:01:01,000 --> 00:01:03,000
I got a function for inserting messages

23
00:01:03,000 --> 00:01:07,000
and I got a function for getting data from the database.

24
00:01:07,000 --> 00:01:11,000
And these are indeed synchronous functions right now

25
00:01:11,000 --> 00:01:13,000
because this better-sqlite free package,

26
00:01:13,000 --> 00:01:16,000
which I'm using for interacting with the database,

27
00:01:16,000 --> 00:01:18,000
indeed does not need promises,

28
00:01:18,000 --> 00:01:21,000
does not need asynchronous code,

29
00:01:21,000 --> 00:01:23,000
and therefore there is no async here.

30
00:01:23,000 --> 00:01:26,000
And hence, we actually also don't have to await this here.

31
00:01:26,000 --> 00:01:28,000
We can even remove async here

32
00:01:28,000 --> 00:01:30,000
if we want to on this component.

33
00:01:32,000 --> 00:01:34,000
So with that, we'll then get our messages here,

34
00:01:34,000 --> 00:01:38,000
which we can output and I can do the same

35
00:01:38,000 --> 00:01:39,000
in my layout.

36
00:01:39,000 --> 00:01:44,000
There, I also no longer wanna fetch my messages like this.

37
00:01:44,000 --> 00:01:47,000
Instead, we can remove async here as well

38
00:01:47,000 --> 00:01:51,000
and get the messages by calling getMessages,

39
00:01:51,000 --> 00:01:54,000
which is that same function from the lib folder.

40
00:01:56,000 --> 00:01:57,000
Now with that,

41
00:01:57,000 --> 00:02:01,000
if I saved it and reload, I got no messages right now,

42
00:02:01,000 --> 00:02:04,000
but that's why I have this addMessage function here.

43
00:02:04,000 --> 00:02:07,000
And I now want to call this function again

44
00:02:07,000 --> 00:02:11,000
from inside this server action in the NewMessages page

45
00:02:11,000 --> 00:02:13,000
and pass the message that has been entered

46
00:02:13,000 --> 00:02:15,000
by the user to addMessage.

47
00:02:15,000 --> 00:02:16,000
And that should add a new message.

48
00:02:19,000 --> 00:02:22,000
And therefore, with this re-added to the code,

49
00:02:22,000 --> 00:02:26,000
if I go here and add a new message like test,

50
00:02:26,000 --> 00:02:28,000
it shows up on that messages page.

51
00:02:28,000 --> 00:02:31,000
If I add test two, that also shows up here.

52
00:02:32,000 --> 00:02:34,000
And the fact

53
00:02:34,000 --> 00:02:38,000
that these messages show up here proves

54
00:02:38,000 --> 00:02:42,000
that there seems to be no caching going on here,

55
00:02:42,000 --> 00:02:44,000
though that's not entirely true.

56
00:02:44,000 --> 00:02:48,000
If you recall, once we start building this application

57
00:02:48,000 --> 00:02:51,000
for production by npm run build,

58
00:02:51,000 --> 00:02:54,000
we do get that page pre-rendering again

59
00:02:54,000 --> 00:02:58,000
and we get that full route cache

60
00:02:58,000 --> 00:03:01,000
unless you set one of these settings here

61
00:03:01,000 --> 00:03:05,000
and force this page to be dynamic, for example.

62
00:03:05,000 --> 00:03:07,000
But otherwise, we get this full route cache

63
00:03:07,000 --> 00:03:10,000
and therefore, when building this for production,

64
00:03:10,000 --> 00:03:14,000
we indeed have the problem that we see any messages,

65
00:03:14,000 --> 00:03:17,000
any data that existed at build time,

66
00:03:17,000 --> 00:03:19,000
but if we add a new message thereafter,

67
00:03:19,000 --> 00:03:21,000
that indeed does now not show up.

68
00:03:22,000 --> 00:03:24,000
So we do have some caching here,

69
00:03:24,000 --> 00:03:26,000
we have that full route cache,

70
00:03:26,000 --> 00:03:29,000
but we don't have that data cache.

71
00:03:29,000 --> 00:03:33,000
We don't have the request deduplication

72
00:03:33,000 --> 00:03:36,000
when using our own custom data source.

73
00:03:36,000 --> 00:03:39,000
Now we'll fix that problem here

74
00:03:39,000 --> 00:03:41,000
of the updated data not appearing

75
00:03:41,000 --> 00:03:43,000
due to the full route cache later.

76
00:03:43,000 --> 00:03:46,000
For now, I'll go back to my development server

77
00:03:46,000 --> 00:03:50,000
and I'll focus on the request deduplication.

78
00:03:50,000 --> 00:03:52,000
And on that full route cache first.

79
00:03:53,000 --> 00:03:56,000
We can also stop that backend server here, by the way.

80
00:03:57,000 --> 00:04:01,000
So my Next.js development server is running again,

81
00:04:01,000 --> 00:04:02,000
and that indeed means

82
00:04:02,000 --> 00:04:03,000
that with the development server,

83
00:04:03,000 --> 00:04:05,000
we see all the updated data

84
00:04:05,000 --> 00:04:08,000
because we don't have that full route cache here.

85
00:04:09,000 --> 00:04:12,000
But it also means if we take a look at the logs here,

86
00:04:12,000 --> 00:04:16,000
that we actually hit the database every time

87
00:04:16,000 --> 00:04:18,000
I reload this page,

88
00:04:18,000 --> 00:04:20,000
and we indeed always hit it twice

89
00:04:20,000 --> 00:04:23,000
because I'm fetching the same messages

90
00:04:23,000 --> 00:04:26,000
both from inside the page and the layout.

91
00:04:26,000 --> 00:04:29,000
It's the same request which triggers

92
00:04:29,000 --> 00:04:31,000
the same SQL command here,

93
00:04:31,000 --> 00:04:33,000
the same query,

94
00:04:33,000 --> 00:04:35,000
but we run this twice because we send it

95
00:04:35,000 --> 00:04:36,000
in two different places.

96
00:04:36,000 --> 00:04:40,000
We got no request deduplication going on here

97
00:04:40,000 --> 00:04:42,000
because we're not using the fetch function

98
00:04:42,000 --> 00:04:44,000
and out of the box,

99
00:04:44,000 --> 00:04:47,000
Next.js only supports that for the next function.

100
00:04:48,000 --> 00:04:52,000
But we can make this request deduplication work

101
00:04:52,000 --> 00:04:54,000
for our own data fetching code

102
00:04:54,000 --> 00:04:56,000
that uses our own data source

103
00:04:56,000 --> 00:04:58,000
with help of another function

104
00:04:58,000 --> 00:05:00,000
that can be imported from React.

105
00:05:00,000 --> 00:05:05,000
So not from Next, but from React.

106
00:05:05,000 --> 00:05:06,000
And from that React library,

107
00:05:06,000 --> 00:05:09,000
we can import a cache function.

108
00:05:12,000 --> 00:05:15,000
Now, this cache function is meant to be wrapped

109
00:05:15,000 --> 00:05:17,000
around one of your functions

110
00:05:17,000 --> 00:05:22,000
for which request deduplication should then occur.

111
00:05:22,000 --> 00:05:25,000
And you can easily use that cache function

112
00:05:25,000 --> 00:05:29,000
by wrapping it around getMessages, like this.

113
00:05:29,000 --> 00:05:31,000
Now, this is now not valid code.

114
00:05:31,000 --> 00:05:33,000
So what we should do here is we should create

115
00:05:33,000 --> 00:05:35,000
a new constant call getMessages

116
00:05:35,000 --> 00:05:38,000
and set that equal to that cached function,

117
00:05:38,000 --> 00:05:39,000
and that's now valid again.

118
00:05:41,000 --> 00:05:43,000
Now, if you do that

119
00:05:43,000 --> 00:05:48,000
and you reload this page, everything works as before.

120
00:05:48,000 --> 00:05:52,000
But what you'll notice is that now, if I clear that here

121
00:05:52,000 --> 00:05:55,000
and rerun my development server,

122
00:05:56,000 --> 00:05:58,000
if I reload this messages page,

123
00:05:58,000 --> 00:06:02,000
there is just one request to the database.

124
00:06:03,000 --> 00:06:08,000
Now we see that one request for every reload I perform,

125
00:06:08,000 --> 00:06:12,000
but it's just one request per page reload instead of two,

126
00:06:12,000 --> 00:06:14,000
because this cache function,

127
00:06:14,000 --> 00:06:15,000
which is provided by React,

128
00:06:15,000 --> 00:06:18,000
when wrapped around one of our functions,

129
00:06:18,000 --> 00:06:21,000
indeed make sure that under the hood,

130
00:06:21,000 --> 00:06:24,000
React cache is the data returned

131
00:06:24,000 --> 00:06:26,000
by that function when it's called the first time

132
00:06:26,000 --> 00:06:28,000
anywhere in our application,

133
00:06:28,000 --> 00:06:31,000
inside of one single request cycle.

134
00:06:31,000 --> 00:06:33,000
And then the response

135
00:06:33,000 --> 00:06:36,000
by that function is reused in all the places

136
00:06:36,000 --> 00:06:38,000
that also call that function

137
00:06:38,000 --> 00:06:41,000
in that same single request cycle.

138
00:06:42,000 --> 00:06:43,000
So if I reload the page

139
00:06:43,000 --> 00:06:45,000
and therefore both the layout component

140
00:06:45,000 --> 00:06:48,000
and the page component are executed in the end

141
00:06:48,000 --> 00:06:49,000
during development,

142
00:06:49,000 --> 00:06:52,000
I make two calls to the getMessages function.

143
00:06:52,000 --> 00:06:55,000
But thanks to this cache function,

144
00:06:55,000 --> 00:06:57,000
only one call is executed

145
00:06:57,000 --> 00:07:00,000
and then the response or the result of the call

146
00:07:00,000 --> 00:07:04,000
is stored and reused for the second call.

147
00:07:04,000 --> 00:07:07,000
So we can therefore enable request deduplication

148
00:07:07,000 --> 00:07:09,000
with our own data source

149
00:07:09,000 --> 00:07:12,000
and our own functions with help of the cache function

150
00:07:12,000 --> 00:07:13,000
provided by React.