1
00:00:00,510 --> 00:00:05,310
In the last video we finished wiring up our new middleware required credits to our app.

2
00:00:05,370 --> 00:00:07,530
Post-rock handler right here.

3
00:00:07,530 --> 00:00:13,320
So now inside of our request handler body we can start to put together some logic to create and save

4
00:00:13,380 --> 00:00:16,930
a new survey to our database after we create the survey.

5
00:00:16,950 --> 00:00:21,450
We can then start to think about how we're going to send out an email to all the different users who

6
00:00:21,450 --> 00:00:24,720
are specified in the survey itself.

7
00:00:24,720 --> 00:00:29,640
Now as we start to go through this process I'm going to tell you that this request handler right here

8
00:00:29,730 --> 00:00:32,760
is going to very shortly grow to be quite large.

9
00:00:32,760 --> 00:00:37,230
There's going to be a lot of logic that we're going to stuff into this request handler body.

10
00:00:37,500 --> 00:00:42,180
So in this video we're going to start off by doing just a little bit of code just to get started just

11
00:00:42,180 --> 00:00:43,470
to get our feet wet.

12
00:00:43,470 --> 00:00:48,420
And then in the next section we're going to talk about what this request handler is really truly going

13
00:00:48,420 --> 00:00:51,880
to do in all the different logic that we're going to stuff inside of it.

14
00:00:52,110 --> 00:00:56,100
So this video is all about just kind of getting our feet wet just kind of putting our toes into the

15
00:00:56,100 --> 00:01:00,930
pool that will then take a break and then talk about exactly how we're going to dive into the deep end

16
00:01:00,930 --> 00:01:02,290
with this.

17
00:01:02,310 --> 00:01:09,570
So to get started the first thing that I want to do is take the incoming request object right here.

18
00:01:09,570 --> 00:01:14,850
Remember we've said several times that when someone wants to create a new survey we're going to expect

19
00:01:14,940 --> 00:01:18,990
the body of the request to contain a couple of different properties.

20
00:01:18,990 --> 00:01:24,960
So the body of the request should contain the title of the survey or like the title of the campaign

21
00:01:25,440 --> 00:01:29,740
the subject line to use for the e-mail the text to show in the body of the e-mail.

22
00:01:29,940 --> 00:01:35,800
And then a comma separated string of e-mail addresses to send the survey to.

23
00:01:35,800 --> 00:01:39,800
And so you might notice that I updated this diagram just a little bit to be very explicit here.

24
00:01:39,870 --> 00:01:45,930
So we're saying that the list of people to send the e-mail to is going to be a comma separated string

25
00:01:46,020 --> 00:01:47,930
of e-mail addresses.

26
00:01:48,440 --> 00:01:49,080
OK.

27
00:01:49,470 --> 00:01:54,410
So I want to make sure that we can access all of these different properties out of the request body.

28
00:01:54,510 --> 00:01:58,040
So it's going to be step number one after we make sure that we can request.

29
00:01:58,050 --> 00:02:01,980
Or can I get a handle on all these different properties coming up the request.

30
00:02:01,980 --> 00:02:08,520
We will use them to create a new instance of a survey using the mongoose model that we set up and just

31
00:02:08,520 --> 00:02:10,340
like one or two videos ago.

32
00:02:10,800 --> 00:02:15,090
So let's first make sure that we can pull all these different properties out of their requests body

33
00:02:16,650 --> 00:02:18,900
back inside of our survey routes file.

34
00:02:18,900 --> 00:02:21,700
I'm going to reference our rec object.

35
00:02:21,750 --> 00:02:23,820
Remember Rock being short for request.

36
00:02:23,850 --> 00:02:28,350
It's the object that represents the incoming request to our application.

37
00:02:28,350 --> 00:02:34,200
Now recall that all of the information that gets passed along inside this request exists on the body

38
00:02:34,200 --> 00:02:36,330
property of that object.

39
00:02:36,360 --> 00:02:41,730
So to get access to all the different properties we're passed along with the request we can say wrapped

40
00:02:41,730 --> 00:02:42,600
up body.

41
00:02:43,200 --> 00:02:47,490
And then if we want to pull off all these different properties that were passed along we can do a little

42
00:02:47,490 --> 00:02:49,740
bit of as 60 structuring.

43
00:02:49,980 --> 00:03:00,990
So off the body property I want to get access to the title subject body and recipient's properties like

44
00:03:01,010 --> 00:03:03,400
some OK.

45
00:03:03,420 --> 00:03:10,140
So again at this point we do not have any logic on our front end that is specifically making requests

46
00:03:10,140 --> 00:03:15,160
to this end point and including all of these different properties in the body of the request.

47
00:03:15,160 --> 00:03:19,060
I'm saying that this is how we're going to design our back and server.

48
00:03:19,170 --> 00:03:23,430
So we're going to design the back end server assuming that we're going to pass along properties and

49
00:03:23,430 --> 00:03:27,900
we're going to make sure that when we move back to the re-acting redux side of our application we will

50
00:03:27,960 --> 00:03:32,940
really make sure that when we pass off all these properties or when we create a new survey on the front

51
00:03:32,940 --> 00:03:37,070
end we pass along all these different properties as well.

52
00:03:37,080 --> 00:03:41,790
So this is not something that you know we're not saying that this is being done already.

53
00:03:41,790 --> 00:03:46,110
We're just saying this is how we want this back and rout to be working.

54
00:03:46,260 --> 00:03:51,570
Now I want to mention that sometimes when you start working from the back end first it feels kind of

55
00:03:51,570 --> 00:03:56,190
like you're pulling a lot of design decisions out of thin air and sometimes it might feel like life

56
00:03:56,190 --> 00:03:58,470
would be easier if you started on the front end.

57
00:03:58,470 --> 00:04:03,810
However I've got to tell you that in reality for a lot of very serious very professional projects you

58
00:04:03,810 --> 00:04:04,610
might work on.

59
00:04:04,800 --> 00:04:10,290
It's a little bit more common to start off working on the back end server and saying OK here's the different

60
00:04:10,290 --> 00:04:11,310
routes we're going to have.

61
00:04:11,370 --> 00:04:17,130
Here are the different requirements of each handler and that's exactly what we've done so far with this

62
00:04:17,310 --> 00:04:18,510
diagram right here.

63
00:04:18,540 --> 00:04:23,580
So a little bit more common in the real world to do the back end design first even though it might feel

64
00:04:23,580 --> 00:04:29,220
like the front end would be a little bit easier to start off with and it was just a little side topic

65
00:04:29,220 --> 00:04:29,890
there.

66
00:04:30,450 --> 00:04:30,770
OK.

67
00:04:30,810 --> 00:04:33,420
So we've now got access to all these different properties.

68
00:04:33,480 --> 00:04:40,440
I now want to use the survey mongoose model that we created just a little bit ago to create a new instance

69
00:04:40,500 --> 00:04:41,540
of a survey.

70
00:04:41,670 --> 00:04:49,290
So a record that will represent this survey being sent out to a bunch of users inside of our Mago database.

71
00:04:49,290 --> 00:04:52,490
So remember that we created that model just a little bit ago.

72
00:04:52,590 --> 00:04:56,450
Inside our models directory as these survey G-S file.

73
00:04:56,520 --> 00:05:02,010
Now before we just require in this survey jazz file remember that we've got a slightly different methodology

74
00:05:02,070 --> 00:05:08,220
of getting access to mongoose models because of one of those issues around running your tests with node

75
00:05:08,250 --> 00:05:09,460
and mongoose.

76
00:05:09,720 --> 00:05:11,280
Very much a side topic here.

77
00:05:11,280 --> 00:05:16,320
Just recall that sometimes if you use mongoose with any type of testing framework it will sometimes

78
00:05:16,320 --> 00:05:20,210
complain if you attempt to require in a model file multiple times.

79
00:05:20,370 --> 00:05:27,700
So just to kind of skirt that issue just to get around it at the top of this file We're going to require

80
00:05:27,700 --> 00:05:33,390
in mongoose and then to get access to the mongoose modeled class that we'd previously created which

81
00:05:33,390 --> 00:05:41,150
we had called surveys will say Konst survey survey is mongoose model.

82
00:05:41,400 --> 00:05:47,190
When we pass in a string with the name of the model that we had assigned to which was surveys.

83
00:05:47,190 --> 00:05:51,480
So again we could certainly require directly out of the survey file right here.

84
00:05:51,510 --> 00:05:57,390
Our mongoose model class we're just taking this slightly different approach to sidestep that issue around

85
00:05:57,390 --> 00:06:03,080
running tests that you might run into at some point in the future if you had tested this project.

86
00:06:03,120 --> 00:06:03,860
OK.

87
00:06:04,500 --> 00:06:07,410
So we've now got the mongoose model class.

88
00:06:07,410 --> 00:06:12,960
Remember that we can use the model class to create an instance of a survey an instance of a survey is

89
00:06:12,960 --> 00:06:15,960
not automatically persisted to our Mongo database.

90
00:06:16,080 --> 00:06:17,760
We just first create the survey.

91
00:06:17,760 --> 00:06:21,660
We can kind of play around with it a little bit and actually save it to the database.

92
00:06:21,660 --> 00:06:25,020
We have to eventually call the Save function on it.

93
00:06:25,020 --> 00:06:30,180
So right now we're going to take these properties that we've got access to from the request body and

94
00:06:30,180 --> 00:06:34,440
we're going to use them to create a new instance of a survey.

95
00:06:34,620 --> 00:06:41,940
So we'll say Konst survey and notice that we're using a lower case survey here to indicate this is an

96
00:06:42,030 --> 00:06:44,030
instance of a survey.

97
00:06:44,190 --> 00:06:50,220
This will be a new survey and we pass in all the different properties that we want to assign to this

98
00:06:50,310 --> 00:06:52,470
new record.

99
00:06:52,470 --> 00:07:00,090
So before we just kind of dive in if you recall our surveys we've said have a title a body a subject

100
00:07:00,180 --> 00:07:01,920
and a list of recipients right here.

101
00:07:01,920 --> 00:07:08,890
And we have said very importantly that the list of recipients was going to be a sub document collection.

102
00:07:08,910 --> 00:07:13,040
So I think that the first couple of properties will be pretty easy and pretty straightforward to set

103
00:07:13,040 --> 00:07:13,390
up.

104
00:07:13,620 --> 00:07:17,580
But we're going to take a quick pause when we get down to the sub document collection right here and

105
00:07:17,580 --> 00:07:20,880
just reiterate exactly how some document collections work.

106
00:07:20,890 --> 00:07:23,450
Make sure we're on the same page there.

107
00:07:23,460 --> 00:07:23,810
Okay.

108
00:07:23,880 --> 00:07:30,180
So back over inside of our survey route's file We're going to take that title and assign it to our new

109
00:07:30,180 --> 00:07:31,270
survey.

110
00:07:31,320 --> 00:07:35,060
Now immediately you will see that the key and the value here are identical.

111
00:07:35,070 --> 00:07:41,250
So we can use a little bit of E6 syntax to condense down to be just Tida like so now we can do the same

112
00:07:41,250 --> 00:07:43,600
thing with the subject and the body as well.

113
00:07:43,800 --> 00:07:48,870
So subject and body now recipients.

114
00:07:48,870 --> 00:07:51,480
So this one's going to be a little bit more interesting.

115
00:07:51,570 --> 00:07:58,320
Remember in our survey schema we had said that the list of recipients was going to be a sub document

116
00:07:58,320 --> 00:08:02,140
collection that uses the recipient schema.

117
00:08:02,430 --> 00:08:07,320
So let's go and glance at the recipient schema really quick just get a reminder of what's going on inside

118
00:08:07,320 --> 00:08:08,760
that schema.

119
00:08:08,850 --> 00:08:14,580
So we had said that every single recipient would have an e-mail property and would have this respondent

120
00:08:14,580 --> 00:08:19,050
property which was going to be a boolean that defaulted to be false.

121
00:08:19,050 --> 00:08:25,950
So really when we think about creating a new recipient we don't have to assign or specifically indicate

122
00:08:26,190 --> 00:08:32,640
what the responded property is it will be automatically defaulted to false for us whenever we create

123
00:08:32,700 --> 00:08:34,030
a new recipient.

124
00:08:34,050 --> 00:08:41,470
So all we really have to care about is making sure that we specify the e-mail as a string OK.

125
00:08:41,770 --> 00:08:46,900
Now creating the subdominant schema here is going to be just a little bit complicated.

126
00:08:46,960 --> 00:08:51,640
So I think that maybe you would be best if we take a quick break and we come back in the next section

127
00:08:51,670 --> 00:08:57,000
and have a nice diagram to look at to understand exactly how we assign the list of recipients here.

128
00:08:57,190 --> 00:08:58,140
So let's do that.

129
00:08:58,150 --> 00:08:59,080
Let's take a break.

130
00:08:59,140 --> 00:09:03,670
We'll come back and we will talk about exactly how we create this document collection.

131
00:09:03,670 --> 00:09:05,730
So I'll see you in just a minute.