1
00:00:03,000 --> 00:00:04,643
By adding an API route

2
00:00:04,643 --> 00:00:07,258
and calling it from the client side

3
00:00:07,258 --> 00:00:09,350
we covered all possible ways

4
00:00:09,350 --> 00:00:11,666
to fetch data in a Next.js app.

5
00:00:12,391 --> 00:00:14,241
So it is now time to decide

6
00:00:14,241 --> 00:00:16,158
which one is the best option

7
00:00:16,158 --> 00:00:17,735
in our particular case.

8
00:00:18,373 --> 00:00:20,211
Let's review our options quickly.

9
00:00:20,711 --> 00:00:24,371
Option 1a is to fetch products on the server side

10
00:00:24,371 --> 00:00:26,089
using "getStaticProps".

11
00:00:26,089 --> 00:00:27,956
This way the product data

12
00:00:27,956 --> 00:00:29,823
is fetched at build time,

13
00:00:29,823 --> 00:00:33,258
and included in the statically generated page,

14
00:00:33,258 --> 00:00:36,171
which means the page loads very quickly

15
00:00:36,171 --> 00:00:39,830
and it's also easily indexable by search engines.

16
00:00:40,778 --> 00:00:43,884
Approach 1b is similar, but with the addition

17
00:00:43,884 --> 00:00:45,748
of the "revalidate" option,

18
00:00:45,748 --> 00:00:49,129
which results in Incremental Static Regeneration.

19
00:00:49,768 --> 00:00:52,439
This means we get all the benefits of

20
00:00:52,439 --> 00:00:54,461
a statically generated page,

21
00:00:54,461 --> 00:00:57,710
but the page will be regenerated periodically

22
00:00:57,710 --> 00:01:01,392
which means that if the data changes in the backend

23
00:01:01,392 --> 00:01:03,775
the page will also be up to date.

24
00:01:03,775 --> 00:01:05,580
The only downside is that

25
00:01:05,580 --> 00:01:07,819
this approach is not compatible

26
00:01:07,819 --> 00:01:10,490
with exporting the website statically

27
00:01:10,490 --> 00:01:12,801
using the "next export" command.

28
00:01:13,879 --> 00:01:16,806
Option 1c uses "getServerSideProps",

29
00:01:16,806 --> 00:01:19,734
which means the data will be fetched

30
00:01:19,734 --> 00:01:22,499
on the server side but at runtime,

31
00:01:22,499 --> 00:01:24,532
that is on every request.

32
00:01:25,276 --> 00:01:27,737
This approach is similar to using

33
00:01:27,737 --> 00:01:30,273
traditional server side frameworks

34
00:01:30,273 --> 00:01:33,182
like Ruby on Rails, or PHP for example,

35
00:01:33,182 --> 00:01:35,271
in that the server generates

36
00:01:35,271 --> 00:01:38,478
the HTML page dynamically on every request.

37
00:01:39,277 --> 00:01:41,344
Moving on, we have option 2a

38
00:01:41,344 --> 00:01:44,668
that is to fetch the data on the client side,

39
00:01:44,668 --> 00:01:46,883
directly from the backend API,

40
00:01:46,883 --> 00:01:49,468
that in our case is the Strapi CMS.

41
00:01:49,468 --> 00:01:52,717
This is a valid approach if we want to fetch

42
00:01:52,717 --> 00:01:54,342
fresh data every time,

43
00:01:54,342 --> 00:01:57,074
and it's ok to access the backend API

44
00:01:57,074 --> 00:01:58,995
directly from the browser.

45
00:02:00,012 --> 00:02:02,274
Alternatively, we can opt for 2b

46
00:02:02,274 --> 00:02:04,961
which is similar but fetching the data

47
00:02:04,961 --> 00:02:06,163
from an API route

48
00:02:06,163 --> 00:02:08,425
that's on this same Next.js app,

49
00:02:08,425 --> 00:02:10,830
so the browser doesn't need access

50
00:02:10,830 --> 00:02:12,174
to the backend API.

51
00:02:13,028 --> 00:02:15,727
This requires writing an API handler,

52
00:02:15,727 --> 00:02:17,989
that runs on the Next.js server

53
00:02:17,989 --> 00:02:21,054
and fetches the data from the backend CMS.

54
00:02:21,700 --> 00:02:24,458
possibly transforming the data in the process.

55
00:02:25,200 --> 00:02:27,479
So we have 5 different options,

56
00:02:27,479 --> 00:02:30,273
which I have summarised in this table.

57
00:02:30,847 --> 00:02:32,275
Which one is the best

58
00:02:32,275 --> 00:02:34,859
depends on your specific requirements,

59
00:02:34,859 --> 00:02:37,307
and the best choice may be different

60
00:02:37,307 --> 00:02:39,211
for different types of data,

61
00:02:39,211 --> 00:02:41,455
even inside the same application.

62
00:02:41,455 --> 00:02:44,039
For example, if you want to be able to

63
00:02:44,039 --> 00:02:46,827
export your app as a fully static website

64
00:02:46,827 --> 00:02:48,935
using the "next export" command

65
00:02:49,911 --> 00:02:52,012
then that means you cannot use

66
00:02:52,012 --> 00:02:54,184
Incremental Static Regeneration

67
00:02:54,184 --> 00:02:55,936
or Server-side Rendering,

68
00:02:55,936 --> 00:02:58,808
so your choice narrows down to 3 options.

69
00:02:59,519 --> 00:03:01,276
While if you want your data

70
00:03:01,276 --> 00:03:03,749
to be easily indexed by search engines

71
00:03:04,314 --> 00:03:06,541
then you need to choose an approach

72
00:03:06,541 --> 00:03:09,214
where the HTML is generated by the server.

73
00:03:09,777 --> 00:03:12,185
To help you with the choice I have prepared

74
00:03:12,685 --> 00:03:14,240
a simple flow chart.

75
00:03:14,740 --> 00:03:16,614
I believe the first question

76
00:03:16,614 --> 00:03:18,421
you should ask yourself is:

77
00:03:18,421 --> 00:03:21,633
is this data going to be the same for all users?

78
00:03:21,633 --> 00:03:24,443
For example, if we have a list of products

79
00:03:24,443 --> 00:03:27,387
in a shop website, then the answer is "yes":

80
00:03:27,387 --> 00:03:29,328
all users that visit our shop

81
00:03:29,328 --> 00:03:31,268
should see the same products.

82
00:03:31,268 --> 00:03:33,008
But if we're talking about

83
00:03:33,008 --> 00:03:35,149
a user profile page for example,

84
00:03:35,149 --> 00:03:37,424
where the user can enter or update

85
00:03:37,424 --> 00:03:38,897
their address details,

86
00:03:38,897 --> 00:03:41,372
in that case the answer will be "no":

87
00:03:41,372 --> 00:03:43,648
each user will see different data.

88
00:03:44,950 --> 00:03:48,143
Now, if the data is the same for all users

89
00:03:48,143 --> 00:03:50,955
that points to a server-side approach

90
00:03:50,955 --> 00:03:53,843
because the server can generate a page

91
00:03:53,843 --> 00:03:55,895
and reuse it for all users,

92
00:03:55,895 --> 00:03:57,795
including search engines.

93
00:03:57,795 --> 00:04:01,139
In this case the next question I propose is:

94
00:04:01,139 --> 00:04:02,659
can the data change?

95
00:04:02,659 --> 00:04:05,167
So if we have a list of products,

96
00:04:05,167 --> 00:04:07,447
can those products be updated,

97
00:04:07,447 --> 00:04:09,499
or can we add new products?

98
00:04:09,499 --> 00:04:12,463
And in that case, do we expect the page

99
00:04:12,463 --> 00:04:15,427
to automatically reflect those changes?

100
00:04:16,762 --> 00:04:18,245
If the answer is "no":

101
00:04:18,245 --> 00:04:20,539
then we can use Static Generation.

102
00:04:21,106 --> 00:04:23,401
If our list of products is fixed,

103
00:04:23,401 --> 00:04:26,530
then we can statically generate the page once

104
00:04:26,530 --> 00:04:28,755
and always return the same page.

105
00:04:29,394 --> 00:04:32,000
On the other hand, if we want our page

106
00:04:32,000 --> 00:04:35,086
to automatically update when the data changes

107
00:04:35,086 --> 00:04:36,801
then the best approach is

108
00:04:36,801 --> 00:04:38,995
Incremental Static Regeneration.

109
00:04:38,995 --> 00:04:42,012
And this is in fact probably the best choice

110
00:04:42,012 --> 00:04:44,207
for the products on our website.

111
00:04:44,207 --> 00:04:47,224
There is a backend CMS, where the shop staff

112
00:04:47,224 --> 00:04:50,173
could go and edit the products at any time,

113
00:04:50,173 --> 00:04:53,465
and we want our website to update automatically.

114
00:04:53,465 --> 00:04:55,385
But it's ok if a new product

115
00:04:55,385 --> 00:04:57,305
doesn't show up immediately,

116
00:04:57,305 --> 00:04:59,019
but say within 5 minutes,

117
00:04:59,019 --> 00:05:02,174
or whatever we set as the "revalidate" period.

118
00:05:03,496 --> 00:05:06,347
Now, let's go back to the initial question,

119
00:05:06,347 --> 00:05:09,263
that is: is the data the same for all users?

120
00:05:09,263 --> 00:05:10,721
If the answer is "no",

121
00:05:10,721 --> 00:05:13,240
which means the data is user-specific,

122
00:05:13,938 --> 00:05:17,638
this points to fetching the data on the client side.

123
00:05:17,638 --> 00:05:19,987
Because we want to fetch the data

124
00:05:19,987 --> 00:05:21,623
for that specific user.

125
00:05:21,623 --> 00:05:24,327
So at this point we should consider if

126
00:05:24,327 --> 00:05:27,315
it's ok to access the backend API directly

127
00:05:27,315 --> 00:05:29,308
from the users' web browser?

128
00:05:30,163 --> 00:05:31,217
If the answer is yes,

129
00:05:31,217 --> 00:05:32,520
then that's what we'll do.

130
00:05:33,070 --> 00:05:35,541
But frequently the answer is "no",

131
00:05:35,541 --> 00:05:38,594
which means we need to write an API route,

132
00:05:38,594 --> 00:05:40,047
that acts as a proxy

133
00:05:40,047 --> 00:05:43,536
between our frontend app running in the browser,

134
00:05:43,536 --> 00:05:46,806
and the backend API where the data is stored.

135
00:05:46,806 --> 00:05:48,986
Now, you may have noticed that

136
00:05:48,986 --> 00:05:51,239
among the possible choices here

137
00:05:51,239 --> 00:05:54,946
I didn't include the "getServerSideProps" approach.

138
00:05:54,946 --> 00:05:57,126
And that's deliberate, because

139
00:05:57,126 --> 00:06:00,033
based on my own experience, with Next.js

140
00:06:00,033 --> 00:06:02,431
there are usually better options.

141
00:06:02,431 --> 00:06:04,393
But that's just my opinion,

142
00:06:04,393 --> 00:06:07,010
maybe you will find a use case where

143
00:06:07,010 --> 00:06:10,353
"getServerSideProps" is in fact a good choice.

144
00:06:10,353 --> 00:06:13,405
So hopefully this flow chart will help you

145
00:06:13,405 --> 00:06:15,585
in choosing the right approach

146
00:06:15,585 --> 00:06:17,257
for your own use cases.

147
00:06:18,919 --> 00:06:21,877
But to go back to our product list example,

148
00:06:21,877 --> 00:06:24,078
I mentioned that the best choice

149
00:06:24,078 --> 00:06:27,104
is probably Incremental Static Regeneration.

150
00:06:27,741 --> 00:06:29,981
So let's now go back to our application,

151
00:06:30,641 --> 00:06:34,050
and select option 1b, that is ISR.

152
00:06:34,550 --> 00:06:37,221
What I'm going to do is copy this whole file

153
00:06:37,221 --> 00:06:39,103
into the original "index" page.

154
00:06:40,150 --> 00:06:42,624
And, we can remove this comment at the top.

155
00:06:43,316 --> 00:06:46,827
Also, we set "revalidate" to 30 seconds for testing,

156
00:06:47,327 --> 00:06:49,798
but a more appropriate value for production

157
00:06:49,798 --> 00:06:51,866
is usually something like 5 minutes.

158
00:06:52,423 --> 00:06:54,963
Ok. At this point we can go and delete

159
00:06:54,963 --> 00:06:56,768
all the other "index" pages

160
00:06:56,768 --> 00:06:59,776
with all the different data fetching options.

161
00:07:00,723 --> 00:07:03,130
And we're left with a single "index" page,

162
00:07:03,130 --> 00:07:05,880
that will be visible at the root of our website.

163
00:07:07,524 --> 00:07:10,466
Now, I actually forgot about our API route.

164
00:07:10,966 --> 00:07:12,824
Since we deleted the version

165
00:07:12,824 --> 00:07:15,279
of the "index" page that was using it

166
00:07:15,279 --> 00:07:17,668
we can delete the API route as well.

167
00:07:18,300 --> 00:07:20,006
And with this, we are ready

168
00:07:20,006 --> 00:07:22,533
to continue developing our shop website,

169
00:07:22,533 --> 00:07:24,491
adding some more functionality.