1
00:00:00,050 --> 00:00:00,470
All right.

2
00:00:00,470 --> 00:00:03,890
And up next, let's talk about validation layer.

3
00:00:04,040 --> 00:00:11,780
And before I show you why we need one, let me again repeat the same speech I was giving for custom

4
00:00:11,780 --> 00:00:12,210
errors.

5
00:00:12,230 --> 00:00:17,150
Yes, It's going to be a little bit painful to set up the validation layer.

6
00:00:17,150 --> 00:00:18,820
But keep in mind one thing.

7
00:00:18,830 --> 00:00:26,420
Not only you'll be able to use it in this project, and as a side note, once we have the main structure

8
00:00:26,420 --> 00:00:33,560
in place as far as just validating single request, it's going to be much faster.

9
00:00:33,740 --> 00:00:40,180
But also you can reuse the same functionality in all your upcoming projects.

10
00:00:40,190 --> 00:00:41,870
Just please keep that in mind.

11
00:00:41,960 --> 00:00:48,080
Now, as far as the example, let me just navigate right now to my Thunder client.

12
00:00:49,130 --> 00:00:55,090
And collections then recording and I want to go with Create Job.

13
00:00:55,100 --> 00:01:01,670
And at the moment I'm sending company and the position and we did cover that technically if we add extra

14
00:01:01,670 --> 00:01:05,060
property, if it's not in our schema, we are good to go.

15
00:01:05,209 --> 00:01:05,930
Correct.

16
00:01:06,110 --> 00:01:12,080
But what do you think happens if we send pretty much nothing if we send empty Json?

17
00:01:12,290 --> 00:01:16,340
Well, actually we create a new instance.

18
00:01:16,370 --> 00:01:19,250
Now of course, the company is missing the position.

19
00:01:19,250 --> 00:01:21,470
We only have the default values.

20
00:01:21,650 --> 00:01:27,800
But you have to agree that this is not the behavior we are expecting.

21
00:01:27,950 --> 00:01:31,610
And if you're already familiar with the mongoose, you know that.

22
00:01:32,380 --> 00:01:39,880
Technically, I can go to my models and I can set up quite extensive validation over here.

23
00:01:40,210 --> 00:01:47,230
But a better approach is to set up a separate layer because again, we can reuse it from project to

24
00:01:47,230 --> 00:01:57,280
project and it's going to be easier for us to catch those errors before the request even gets into the

25
00:01:57,280 --> 00:01:58,150
controller.

26
00:01:58,650 --> 00:02:03,540
So one way would be again, setting up over here all the validation.

27
00:02:03,570 --> 00:02:10,580
Another way how we could handle technically validation is in the controllers directly.

28
00:02:10,590 --> 00:02:12,990
But here's the issue.

29
00:02:13,110 --> 00:02:19,410
The more validation you add over here in the controller, just like we saw with company and position,

30
00:02:19,410 --> 00:02:23,790
I believe we used it in the update job, if I'm not mistaken.

31
00:02:24,340 --> 00:02:30,550
The more code you will have and it's going to be harder to maintain the controllers.

32
00:02:31,630 --> 00:02:37,270
Our goal is to have pretty much controllers as slim as possible.

33
00:02:37,270 --> 00:02:45,520
And that's why we'll set up a separate layer which checks for those values before they even get to the

34
00:02:45,520 --> 00:02:46,380
controllers.

35
00:02:46,390 --> 00:02:48,880
And that way again, we can reuse it.

36
00:02:48,910 --> 00:02:55,960
Our controllers are going to be way slimmer, so we won't have to add that much logic in here.

37
00:02:56,470 --> 00:03:02,650
And also we won't have to implement any kind of validation here in the schema.

38
00:03:02,950 --> 00:03:07,030
And once we're clear why we need validation layer in the first place.

39
00:03:07,060 --> 00:03:10,270
Now let's roll up our sleeves and get to work.