1
00:00:02,000 --> 00:00:04,000
Okay, let's now solve this together.

2
00:00:04,000 --> 00:00:07,000
We wanna add a couple of API routes here

3
00:00:07,000 --> 00:00:10,000
so that we can have our own server-side logic

4
00:00:10,000 --> 00:00:14,000
which is detached from rendering pages.

5
00:00:14,000 --> 00:00:15,000
And you'll learn how that works.

6
00:00:15,000 --> 00:00:17,000
In the pages folder

7
00:00:17,000 --> 00:00:22,000
you add that special API folder, which has to be called API.

8
00:00:22,000 --> 00:00:25,000
And in there you can now again create

9
00:00:25,000 --> 00:00:28,000
any file and folder structure of your choice

10
00:00:28,000 --> 00:00:31,000
to define the different API routes and the paths

11
00:00:31,000 --> 00:00:34,000
leading to those routes you wanna use.

12
00:00:34,000 --> 00:00:38,000
For example, we could add a newsletter JS file

13
00:00:38,000 --> 00:00:40,000
for the newsletter related logic.

14
00:00:41,000 --> 00:00:45,000
Then you learn that an API route in the end just is

15
00:00:45,000 --> 00:00:49,000
a function inside of that API route file

16
00:00:49,000 --> 00:00:52,000
which you should export like this.

17
00:00:52,000 --> 00:00:56,000
And this function receives a request and the response object

18
00:00:56,000 --> 00:00:59,000
automatically passed in by next JS

19
00:00:59,000 --> 00:01:03,000
when it executes this function for incoming requests.

20
00:01:03,000 --> 00:01:07,000
Here we can then check the request method, for example

21
00:01:07,000 --> 00:01:10,000
to only proceed for a post requests.

22
00:01:10,000 --> 00:01:14,000
And we can do this here for the email registration

23
00:01:14,000 --> 00:01:17,000
because whilst this is the only kind of method

24
00:01:17,000 --> 00:01:19,000
I wanna support here

25
00:01:19,000 --> 00:01:22,000
I wanna make sure that no other method

26
00:01:22,000 --> 00:01:24,000
triggers any logic here.

27
00:01:24,000 --> 00:01:27,000
So I explicitly check if the incoming request

28
00:01:27,000 --> 00:01:31,000
is a post request and I only wanna proceed in that case

29
00:01:31,000 --> 00:01:34,000
because in that case I for example also know

30
00:01:34,000 --> 00:01:38,000
that I can extract data from the request body.

31
00:01:38,000 --> 00:01:42,000
Because for example, get requests would not carry any data.

32
00:01:43,000 --> 00:01:47,000
So with that, we can extract data from the request body

33
00:01:47,000 --> 00:01:49,000
and we can do it as with the request body field

34
00:01:49,000 --> 00:01:51,000
as you learned.

35
00:01:51,000 --> 00:01:54,000
Here, we could then expect that we have an email field

36
00:01:54,000 --> 00:01:56,000
and that's up to you.

37
00:01:56,000 --> 00:01:59,000
You are the developer of this site.

38
00:01:59,000 --> 00:02:03,000
So it's up to you, how you transmit your data.

39
00:02:03,000 --> 00:02:06,000
And I will therefore expect an email field.

40
00:02:06,000 --> 00:02:08,000
So the user email is then extracted

41
00:02:08,000 --> 00:02:10,000
from the incoming request.

42
00:02:11,000 --> 00:02:13,000
Now here we could then also validate this

43
00:02:13,000 --> 00:02:17,000
and check if it's maybe not valid or

44
00:02:17,000 --> 00:02:18,000
if email,

45
00:02:19,000 --> 00:02:21,000
user email I mean

46
00:02:21,000 --> 00:02:24,000
does maybe not include @ symbol.

47
00:02:24,000 --> 00:02:27,000
Which is a very basic email validation

48
00:02:27,000 --> 00:02:30,000
you might want to implement more (indistinct) one

49
00:02:30,000 --> 00:02:32,000
but it's a start.

50
00:02:32,000 --> 00:02:35,000
And such server-side validation is optional

51
00:02:35,000 --> 00:02:37,000
but strongly recommended.

52
00:02:37,000 --> 00:02:41,000
Because even if you add validation and checks

53
00:02:41,000 --> 00:02:45,000
in your front-end code, those validation steps

54
00:02:45,000 --> 00:02:47,000
can always be circumvented.

55
00:02:47,000 --> 00:02:52,000
After all all your front-end code is exposed to your users

56
00:02:52,000 --> 00:02:54,000
so they could also manipulate it.

57
00:02:54,000 --> 00:02:57,000
So you shouldn't rely on front-end validation

58
00:02:57,000 --> 00:03:01,000
front-end validation is always just a convenience feature

59
00:03:01,000 --> 00:03:03,000
for your users.

60
00:03:03,000 --> 00:03:07,000
Instead to really make sure that you get valid data

61
00:03:07,000 --> 00:03:10,000
and that you work with valid data

62
00:03:10,000 --> 00:03:13,000
you should validate in your API route

63
00:03:13,000 --> 00:03:18,000
because this code can't be viewed or changed by your users.

64
00:03:18,000 --> 00:03:21,000
Now for this task here, it's optional.

65
00:03:21,000 --> 00:03:24,000
I did not tell you to add such validation.

66
00:03:24,000 --> 00:03:28,000
So if you did not do that, that's totally fine.

67
00:03:28,000 --> 00:03:30,000
I just wants to bring it up here

68
00:03:30,000 --> 00:03:33,000
because it is important is to be aware of the role

69
00:03:33,000 --> 00:03:36,000
server-side validation plays.

70
00:03:36,000 --> 00:03:39,000
Now, here we could then return to cancel

71
00:03:39,000 --> 00:03:42,000
the (indistinct) function execution if we make it in here.

72
00:03:42,000 --> 00:03:46,000
So if we have invalid data and we could return a response

73
00:03:46,000 --> 00:03:49,000
with a status code of 422

74
00:03:49,000 --> 00:03:51,000
which is a status code signaling that

75
00:03:51,000 --> 00:03:56,000
the user input was bad, and then maybe set a message of

76
00:03:56,000 --> 00:03:59,000
invalid email address.

77
00:03:59,000 --> 00:04:00,000
Something like this.

78
00:04:00,000 --> 00:04:04,000
And we would send this response back to the user

79
00:04:04,000 --> 00:04:06,000
if the input is invalid.

80
00:04:06,000 --> 00:04:09,000
And there after I return to cancel the function execution

81
00:04:09,000 --> 00:04:13,000
because I will add more code after this if check

82
00:04:13,000 --> 00:04:15,000
and I don't want to execute that code

83
00:04:15,000 --> 00:04:20,000
if we have invalid input, hence the return statement.

84
00:04:20,000 --> 00:04:23,000
Now, if we do make it past this if block though

85
00:04:23,000 --> 00:04:26,000
we know that we do have a valid user input

86
00:04:26,000 --> 00:04:28,000
and then we could store it in a database

87
00:04:28,000 --> 00:04:30,000
or anything like that.

88
00:04:30,000 --> 00:04:31,000
And for the moment we'll not do this

89
00:04:31,000 --> 00:04:35,000
for the moment I'll just console log, that user email.

90
00:04:35,000 --> 00:04:38,000
And that is now a first API route

91
00:04:38,000 --> 00:04:40,000
as we could write it.

92
00:04:40,000 --> 00:04:45,000
An API route for extracting an incoming email address.

93
00:04:45,000 --> 00:04:48,000
Now we wanna send a request to this API route

94
00:04:48,000 --> 00:04:49,000
and we wanna do that

95
00:04:49,000 --> 00:04:52,000
from inside the components input folder

96
00:04:52,000 --> 00:04:55,000
from inside the newsletter registration file.

97
00:04:55,000 --> 00:04:57,000
Here we have the registration handler

98
00:04:57,000 --> 00:05:01,000
which is triggered when the form is submitted.

99
00:05:01,000 --> 00:05:04,000
And here I am preventing the browser default then

100
00:05:04,000 --> 00:05:07,000
to a wide that the page has reloaded.

101
00:05:07,000 --> 00:05:10,000
Now we could also validate the user input here

102
00:05:10,000 --> 00:05:13,000
and show an error message if it is invalid

103
00:05:13,000 --> 00:05:17,000
again, validation here is then just a convenience feature

104
00:05:17,000 --> 00:05:20,000
to show some feedback to the user quickly.

105
00:05:20,000 --> 00:05:22,000
It's not something you should rely on

106
00:05:22,000 --> 00:05:24,000
and it's not something I will add here

107
00:05:24,000 --> 00:05:27,000
because it has nothing to do with API routes

108
00:05:27,000 --> 00:05:30,000
but of course feel free to add it in your solution.

109
00:05:31,000 --> 00:05:34,000
Now, in my case here, I will not add it.

110
00:05:34,000 --> 00:05:38,000
I instead wanna send that HTTP request to the API route

111
00:05:38,000 --> 00:05:40,000
we just added.

112
00:05:40,000 --> 00:05:41,000
And again we can, for example

113
00:05:41,000 --> 00:05:43,000
do this with the fetch function

114
00:05:43,000 --> 00:05:45,000
which is built into the browser.

115
00:05:45,000 --> 00:05:49,000
Now for the URL you'll learned that the API route

116
00:05:49,000 --> 00:05:53,000
is hosted by the same server as our pages are

117
00:05:53,000 --> 00:05:56,000
sent back from so it's the same domain.

118
00:05:56,000 --> 00:05:59,000
And hence can just construct an absolute path

119
00:05:59,000 --> 00:06:04,000
to the API route with /api/newsletter in this case.

120
00:06:05,000 --> 00:06:10,000
/newsletter because I named my API route file, newsletter.

121
00:06:11,000 --> 00:06:13,000
If you named it differently you have to use

122
00:06:13,000 --> 00:06:16,000
a different identifier here in your URL.

123
00:06:18,000 --> 00:06:20,000
Now we wanna send a post request

124
00:06:20,000 --> 00:06:24,000
because we need to add some data to the outgoing requests

125
00:06:24,000 --> 00:06:29,000
and hence here all at this configuration object to fetch

126
00:06:29,000 --> 00:06:33,000
where we can set methods to post and then add a body.

127
00:06:33,000 --> 00:06:37,000
Now, speaking of that body, we need to get access to the

128
00:06:37,000 --> 00:06:39,000
input value here.

129
00:06:39,000 --> 00:06:41,000
And there are two main ways of doing that

130
00:06:41,000 --> 00:06:46,000
we can add state and update the state with every keystroke

131
00:06:46,000 --> 00:06:48,000
or we use a ref and I'll do the letter

132
00:06:48,000 --> 00:06:51,000
since I only need access to the input once

133
00:06:51,000 --> 00:06:52,000
when the form is submitted.

134
00:06:53,000 --> 00:06:55,000
So for this I'll use useRef,

135
00:06:55,000 --> 00:06:57,000
which we need to import from react

136
00:06:58,000 --> 00:07:02,000
and we can create our email inputRef here

137
00:07:02,000 --> 00:07:04,000
like this

138
00:07:04,000 --> 00:07:06,000
and then connect it to the input element.

139
00:07:06,000 --> 00:07:09,000
By adding the special ref prop and pointing at email

140
00:07:09,000 --> 00:07:11,000
inputRef like that.

141
00:07:12,000 --> 00:07:14,000
Now this is connected

142
00:07:14,000 --> 00:07:17,000
and now here we can extract our entered email

143
00:07:17,000 --> 00:07:20,000
inside of this registration handler.

144
00:07:20,000 --> 00:07:22,000
We can get the entered email

145
00:07:22,000 --> 00:07:25,000
by reaching out to the email inputRef.current

146
00:07:25,000 --> 00:07:27,000
because that's how refs work

147
00:07:27,000 --> 00:07:31,000
.value to get the currently entered value.

148
00:07:31,000 --> 00:07:34,000
And that's then what I wanna send to the back-end.

149
00:07:34,000 --> 00:07:38,000
Now we need to send our data as JSON data here.

150
00:07:38,000 --> 00:07:41,000
So call JSON.stringIfy.

151
00:07:41,000 --> 00:07:45,000
And I'll pass in an object where I set a email property

152
00:07:45,000 --> 00:07:47,000
to entered email.

153
00:07:47,000 --> 00:07:50,000
And this should be a email property

154
00:07:50,000 --> 00:07:52,000
because in the API route

155
00:07:52,000 --> 00:07:55,000
I'm extracting a email property on my body.

156
00:07:55,000 --> 00:07:59,000
So I'm looking for a email property in my body.

157
00:07:59,000 --> 00:08:02,000
So if you chose a different identifier here

158
00:08:02,000 --> 00:08:04,000
for extracting the data

159
00:08:04,000 --> 00:08:06,000
you also need to choose a different property

160
00:08:06,000 --> 00:08:08,000
when you send the data.

161
00:08:08,000 --> 00:08:11,000
I'm using email so I'm using it in both places.

162
00:08:12,000 --> 00:08:14,000
And then last but not least, I'll add headers

163
00:08:14,000 --> 00:08:18,000
and set a special content type header like this

164
00:08:18,000 --> 00:08:20,000
and set this to application json

165
00:08:20,000 --> 00:08:24,000
to make the API routes aware of the type of data

166
00:08:24,000 --> 00:08:26,000
my request body will carry.

167
00:08:26,000 --> 00:08:29,000
And that will be json data, because I convert my data

168
00:08:29,000 --> 00:08:33,000
to json with JSON.stringify.

169
00:08:33,000 --> 00:08:36,000
So this sends a request to the API route

170
00:08:36,000 --> 00:08:39,000
and now we can of course handle the response

171
00:08:39,000 --> 00:08:42,000
and then the response data if we want to

172
00:08:42,000 --> 00:08:46,000
so here I'll just get access to the response

173
00:08:46,000 --> 00:08:47,000
data

174
00:08:47,000 --> 00:08:49,000
by calling the json method.

175
00:08:49,000 --> 00:08:52,000
And then here we can console log that data

176
00:08:52,000 --> 00:08:55,000
to just console log the response.

177
00:08:56,000 --> 00:08:57,000
And speaking off the response

178
00:08:57,000 --> 00:09:00,000
there's one thing missing in the API route.

179
00:09:00,000 --> 00:09:02,000
I do send the response here

180
00:09:02,000 --> 00:09:05,000
if we have an invalid email address

181
00:09:05,000 --> 00:09:08,000
but we should absolutely also send the response

182
00:09:08,000 --> 00:09:10,000
if we have a valid one.

183
00:09:10,000 --> 00:09:14,000
So in this scenario, after console logging the entered email

184
00:09:14,000 --> 00:09:18,000
I'll send a response with a status code of 201

185
00:09:18,000 --> 00:09:22,000
which means success, a resource was added.

186
00:09:22,000 --> 00:09:24,000
So the email was stored.

187
00:09:24,000 --> 00:09:27,000
And then we can send back any kind of data,

188
00:09:27,000 --> 00:09:30,000
like for example @json object.

189
00:09:30,000 --> 00:09:33,000
So a JavaScript object converted to json

190
00:09:33,000 --> 00:09:35,000
with help of that json method.

191
00:09:35,000 --> 00:09:39,000
Where we add a message property where we could say

192
00:09:39,000 --> 00:09:41,000
signed up.

193
00:09:41,000 --> 00:09:43,000
Anything like this.

194
00:09:43,000 --> 00:09:45,000
If we do that and save this

195
00:09:47,000 --> 00:09:49,000
we can check if this works.

196
00:09:49,000 --> 00:09:53,000
If we reload our application and open our

197
00:09:53,000 --> 00:09:55,000
developer tools

198
00:09:55,000 --> 00:09:58,000
if I enter something invalid here

199
00:09:58,000 --> 00:10:02,000
I get a warning from my browser, actually,

200
00:10:02,000 --> 00:10:04,000
because this is of type email.

201
00:10:04,000 --> 00:10:07,000
So we have to add something valid here as well.

202
00:10:07,000 --> 00:10:09,000
Though that could be disabled in the browser.

203
00:10:09,000 --> 00:10:11,000
So we should not rely on it.

204
00:10:11,000 --> 00:10:13,000
But if I do enter a valid email address here

205
00:10:13,000 --> 00:10:16,000
and I click register, that's looking good

206
00:10:16,000 --> 00:10:19,000
because I'm printing that response data here

207
00:10:19,000 --> 00:10:21,000
which says signed up.

208
00:10:21,000 --> 00:10:24,000
And then the network tab, we also see that

209
00:10:24,000 --> 00:10:27,000
this request was sent successfully

210
00:10:27,000 --> 00:10:31,000
and that we got this 201 status code back.

211
00:10:31,000 --> 00:10:35,000
And if we have a look at our service side terminal here

212
00:10:35,000 --> 00:10:38,000
so this terminal where we started npm run (indistinct)

213
00:10:38,000 --> 00:10:42,000
where all our service-side logs will be printed

214
00:10:42,000 --> 00:10:45,000
we see that test@test.com is output here

215
00:10:45,000 --> 00:10:48,000
and that makes sense because we are console logging

216
00:10:48,000 --> 00:10:53,000
the arriving email address here in our API route.

217
00:10:53,000 --> 00:10:58,000
So this is now working and you can certainly enhance this

218
00:10:58,000 --> 00:11:02,000
and improve error handling or do anything like that

219
00:11:02,000 --> 00:11:05,000
but this is the core functionality

220
00:11:05,000 --> 00:11:06,000
which you should add here

221
00:11:06,000 --> 00:11:08,000
as your first task.

