1
00:00:02,010 --> 00:00:05,030
We're gonna start working on our different root handlers inside this video.

2
00:00:05,070 --> 00:00:05,950
The first right handler.

3
00:00:05,970 --> 00:00:11,730
We're gonna work on is the create order route and make sure that a user can make a poster crust to create

4
00:00:11,760 --> 00:00:17,050
an order whenever a user makes a supposed request they're going to include a ticket I.D. inside the

5
00:00:17,050 --> 00:00:17,930
body the request.

6
00:00:18,040 --> 00:00:20,640
And that's gonna be the ticket that the user is trying to purchase.

7
00:00:22,130 --> 00:00:27,260
Now we definitely are going to want to make sure that only users who are authenticated are able to access

8
00:00:27,260 --> 00:00:28,250
this root handler.

9
00:00:28,250 --> 00:00:33,430
So if you are not authenticated if you're not signed in you do not get to create an order.

10
00:00:33,470 --> 00:00:37,300
So with all that minds let's go back over to our new handler file.

11
00:00:37,360 --> 00:00:43,950
We could start to put together some implementation for this rabbit handler inside my order service.

12
00:00:43,950 --> 00:00:46,330
I'll find the roots directory and new dot.

13
00:00:46,340 --> 00:00:51,350
Yes inside there then at the very top I'm going to import a couple of things that we are probably going

14
00:00:51,350 --> 00:01:00,050
to need inside of here so I'm going to get the require auth middleware and the validate request middleware

15
00:01:00,170 --> 00:01:02,380
from our custom module.

16
00:01:02,390 --> 00:01:04,810
So for me that is SGI ticket slash common.

17
00:01:04,820 --> 00:01:10,080
Remember you have a different organization named right there.

18
00:01:10,130 --> 00:01:16,160
I'm also going to get the body function from Express validator.

19
00:01:16,160 --> 00:01:20,320
So right now words can make sure that a user is authenticated and we're going to make sure that they

20
00:01:20,320 --> 00:01:26,990
are passing in some ticket I.D. in the body the request the right after our route name right there.

21
00:01:27,010 --> 00:01:32,120
I'm going to put in require us to make sure that a user is authenticated and then right after that I'm

22
00:01:32,120 --> 00:01:37,650
going to put in an array and list out my different validators inside of here.

23
00:01:37,710 --> 00:01:44,000
The only thing we really need to truly validate is that ticket items property so we might write in something

24
00:01:45,020 --> 00:01:46,560
like body.

25
00:01:46,640 --> 00:01:51,400
Take a look at the ticket items property and let's just make sure that that thing is defined.

26
00:01:51,410 --> 00:01:59,980
So we might say not is empty and then we can put a custom error message on there of with message and

27
00:01:59,980 --> 00:02:03,740
say ticket I.D. must be provided

28
00:02:06,890 --> 00:02:12,680
now this right here definitely works and it definitely is a good validation step but there's potentially

29
00:02:12,680 --> 00:02:16,540
a one other step of validation we could potentially do inside of here.

30
00:02:16,820 --> 00:02:22,430
When a user passes in a ticket idea property that is a reference to another ticket or some ticket inside

31
00:02:22,430 --> 00:02:23,460
of our system.

32
00:02:23,750 --> 00:02:29,120
And you and I know because the ticket ideas are stored these tickets are stored inside a mongo DV that

33
00:02:29,120 --> 00:02:34,130
this ticket idea property right here should have the structure of an Mongo I.D..

34
00:02:34,160 --> 00:02:36,200
So in other words it should be a string of characters.

35
00:02:36,260 --> 00:02:40,470
That's what is it like twenty four characters twelve or 24 I forget off the top of my head.

36
00:02:40,490 --> 00:02:43,880
Essentially it should look like a mongo DV I.D..

37
00:02:44,180 --> 00:02:46,610
So an idea of something like one two three.

38
00:02:47,000 --> 00:02:50,860
Well that would pass this validation step but that is not a valid I.D..

39
00:02:51,530 --> 00:02:56,120
So we might want to add in a little Czech right here and make sure that whatever the user provided has

40
00:02:56,120 --> 00:03:02,140
the structure of a real Mongo I.D. Now that would definitely be a valuable check here.

41
00:03:02,160 --> 00:03:04,820
But it's also just a little bit dangerous.

42
00:03:04,840 --> 00:03:12,060
And the reason for that is that we would now have one service our order service that is making assumption

43
00:03:12,240 --> 00:03:17,190
or an assumption about the database that is used by the tickets service over here.

44
00:03:17,190 --> 00:03:20,700
So there is a little bit of coupling that we're doing between these two services.

45
00:03:20,730 --> 00:03:26,970
If we start to say oh yeah you must be providing me specifically a mongo DV I.D. at some point in the

46
00:03:26,970 --> 00:03:32,140
future we might decide to change out the database used by the ticket service to some other kind of database.

47
00:03:32,220 --> 00:03:36,780
And when we do that well we might not be using Mongo DB anymore we might have a totally different structure

48
00:03:36,810 --> 00:03:37,910
of I.D..

49
00:03:38,100 --> 00:03:39,200
This is a very small thing.

50
00:03:39,210 --> 00:03:43,410
It's just something I want to throw out there that by just assuming that this ticket idea is going to

51
00:03:43,410 --> 00:03:44,740
have a particular structure.

52
00:03:44,810 --> 00:03:49,590
We are kind of coupling our application in a very subtle way with the ticket service.

53
00:03:49,600 --> 00:03:51,820
You might say Steven What does that matter.

54
00:03:51,840 --> 00:03:55,950
We're already using information from the ticket service you're telling us that we're going to replicate

55
00:03:55,950 --> 00:03:58,440
tickets directly from the ticket service.

56
00:03:58,440 --> 00:04:05,400
Well yes we are replicating data over from that service but well what would happen if we just deleted

57
00:04:05,400 --> 00:04:09,160
the service entirely but still issued these events right here.

58
00:04:09,180 --> 00:04:14,460
So maybe there are some other service not called ticket service our order service doesn't really care

59
00:04:14,460 --> 00:04:18,160
about who even these events it just cares that someone emits these events.

60
00:04:18,360 --> 00:04:21,710
So the ticket service really truly can just totally disappear.

61
00:04:21,780 --> 00:04:24,810
It can change structure it can do something dramatically different.

62
00:04:24,870 --> 00:04:31,490
And as long as these events are still being emitted we are happy campers but that is not quite true.

63
00:04:31,540 --> 00:04:37,000
If we start to directly make assumptions about what the service looks like and that's what we are doing

64
00:04:37,210 --> 00:04:41,980
if we add in a check to make sure that the incoming I.D. is actually a mongo I.D..

65
00:04:42,550 --> 00:04:43,530
So I just want throw it out there.

66
00:04:43,540 --> 00:04:45,270
Once again just something to be aware of.

67
00:04:45,310 --> 00:04:47,120
Just something to think about.

68
00:04:47,230 --> 00:04:51,640
So we are going to add in the check to make sure that this does look like a real Mongo I.D. just so

69
00:04:51,640 --> 00:04:56,170
you know how this would be done and if you don't like this idea of making assumptions about how that

70
00:04:56,170 --> 00:04:58,090
service is put together you can always remove it.

71
00:04:58,150 --> 00:05:00,760
So here's how we would do that check at the very top.

72
00:05:00,760 --> 00:05:07,460
We will import Mongoose from Mongoose then right after making sure that the ticket I.D. property is

73
00:05:07,460 --> 00:05:08,300
not empty.

74
00:05:08,300 --> 00:05:11,460
We'll put on a custom validation step.

75
00:05:11,520 --> 00:05:15,630
We're going to say that we're going to expect to get some input to this little custom validation function

76
00:05:15,630 --> 00:05:20,190
that is going to be a string and inside of here we're going to return a boolean to decide whether or

77
00:05:20,190 --> 00:05:26,400
not whatever string the user just provided is actually a valid Mongo I.D. we will write out instead

78
00:05:26,400 --> 00:05:35,810
of your Mongoose types with a capital T object I.D. with a lowercase d on their is valid and then we'll

79
00:05:35,810 --> 00:05:38,410
pass in that input.

80
00:05:38,440 --> 00:05:43,060
So this is just gonna make sure that the user is providing a valid Mongo I.D..

81
00:05:43,060 --> 00:05:45,040
And again if you want to do that just delete it.

82
00:05:45,040 --> 00:05:47,550
No problem whatsoever.

83
00:05:47,570 --> 00:05:48,320
That looks good.

84
00:05:48,320 --> 00:05:52,340
Now after doing the validation step right there we do need to make sure that if anything went wrong

85
00:05:52,340 --> 00:05:56,410
with the validation step we reject the request right away and send back an error message.

86
00:05:56,510 --> 00:05:59,260
And that was the purpose of that validate request middleware.

87
00:05:59,330 --> 00:06:05,060
They'll put in validate requests right there.

88
00:06:05,180 --> 00:06:06,290
Looks good.

89
00:06:06,290 --> 00:06:13,100
Let's say that at present we do not have any way of testing this code unless we pull out postmen and

90
00:06:13,100 --> 00:06:15,250
starts making requests directly.

91
00:06:15,290 --> 00:06:19,490
So we are going to write tests around these root handlers very similar to how we did back on our test

92
00:06:19,550 --> 00:06:21,000
our ticketing service.

93
00:06:21,010 --> 00:06:24,800
We're going to write out all the tests after we create each individual right handler.

94
00:06:24,830 --> 00:06:29,090
So if you don't like the entire testing process if you just don't care about tests no problem.

95
00:06:29,090 --> 00:06:32,930
I'll give you the completed test code and you can always copy paste it over if you want to be able to

96
00:06:32,930 --> 00:06:34,650
run the tests yourself.

97
00:06:34,780 --> 00:06:37,300
Let's keep working on this in the next video.

98
00:06:37,300 --> 00:06:40,600
Then once we are done with this right handler we'll start to write out a couple of different tests around

99
00:06:40,600 --> 00:06:40,880
it.

100
00:06:40,900 --> 00:06:42,070
We'll see you in just a minute.

101
00:06:42,070 --> 00:06:42,910
Let's finish this thing up.