1 00:00:00,720 --> 00:00:02,550 All right my friends this is it. 2 00:00:02,680 --> 00:00:07,380 The last section the last big feature were at the very end of the application. 3 00:00:07,390 --> 00:00:13,330 I know it's been a very long course but remember we have covered a tremendous amount of ground. 4 00:00:13,450 --> 00:00:15,730 So I'm really excited to finish this thing up. 5 00:00:15,730 --> 00:00:22,060 The last feature that we have to work on is thankfully also one of the easiest in the entire application. 6 00:00:22,060 --> 00:00:27,490 So really the last big thing that we have to do is make sure that whenever a user goes to the dashboard 7 00:00:27,490 --> 00:00:32,040 component we show them a list of all the different surveys that they have created. 8 00:00:32,410 --> 00:00:38,560 So basically whenever the user goes to the dashboard we need to make a request to our back end API to 9 00:00:38,560 --> 00:00:43,080 get all of the different surveys that the current user has created. 10 00:00:43,150 --> 00:00:45,540 And so that's that last part is very important. 11 00:00:45,550 --> 00:00:49,100 So here's our survey routes that we had been planning out all this time. 12 00:00:49,300 --> 00:00:55,360 So we're going to put together this route Whenever someone makes a request to API slash surveys we want 13 00:00:55,360 --> 00:00:59,910 to return the list of surveys created specifically by the current user. 14 00:00:59,920 --> 00:01:04,200 Not all the surveys just the ones that have been created by the current user. 15 00:01:04,360 --> 00:01:07,570 So we're going to first tackle this on the back end of our application. 16 00:01:07,570 --> 00:01:12,820 We'll make sure that we can produce a list of surveys and then once we have the back end working we'll 17 00:01:12,820 --> 00:01:19,570 then flip on over the front end and integrate all this stuff into the react and redux sides of her application. 18 00:01:19,570 --> 00:01:25,810 Now even though I've said that this is the easiest feature in the course there still is a kind of interesting 19 00:01:26,620 --> 00:01:31,090 Odan and or two of you know a little little bit of interesting challenges in here somewhat. 20 00:01:31,090 --> 00:01:35,030 So let's make sure we still stay on our toes and finished nice and strong. 21 00:01:35,540 --> 00:01:35,840 OK. 22 00:01:35,890 --> 00:01:37,360 So let's get started right now. 23 00:01:37,360 --> 00:01:39,550 No need to take a break or anything. 24 00:01:39,550 --> 00:01:45,040 So the first thing we're going to do is create a new route handler to respond to any GET request made 25 00:01:45,040 --> 00:01:48,190 to API slash surveys. 26 00:01:48,190 --> 00:01:53,560 So given that this is some route having to do with surveys I think that we should go back into our route's 27 00:01:53,560 --> 00:01:56,110 directory and find the survey route's file. 28 00:01:56,110 --> 00:02:00,470 And I think this would be inappropriate location to add this last route handler. 29 00:02:00,910 --> 00:02:08,630 So inside of our module exports function right here we're going to add in another route definition. 30 00:02:08,800 --> 00:02:18,700 So we'll save anyone makes a get type requests to API slash surveys then respond with all of the surveys 31 00:02:18,700 --> 00:02:20,720 created by the current user. 32 00:02:20,760 --> 00:02:21,950 There you go. 33 00:02:22,780 --> 00:02:23,220 OK. 34 00:02:23,500 --> 00:02:29,710 So reading this actual query to reach into our database and fetch out all the different surveys really 35 00:02:29,710 --> 00:02:34,120 won't be that bad but there's going to be one or two things along the way where we just need to be kind 36 00:02:34,120 --> 00:02:38,100 of cognisant of the amount of data that we're loading and sending back to our user. 37 00:02:38,200 --> 00:02:42,020 So we're going to first start off by taking a somewhat naive approach. 38 00:02:42,020 --> 00:02:45,380 All right we're going to do this the easiest most straightforward way possible. 39 00:02:45,460 --> 00:02:50,440 And then once we implement it we'll kind of see that we might run into a difficulty or two in the future. 40 00:02:50,440 --> 00:02:54,430 And so we'll come back to this route handler and do a little refactor to it. 41 00:02:54,430 --> 00:02:56,820 Now the Reflektor we're going to do is very very small. 42 00:02:56,830 --> 00:03:01,060 So don't don't be sitting there thinking that we're going to write some really awful code. 43 00:03:01,180 --> 00:03:02,810 We're going to write totally fine code. 44 00:03:02,920 --> 00:03:06,580 Just going to point one thing out after we're all done with everything. 45 00:03:07,480 --> 00:03:07,820 OK. 46 00:03:07,840 --> 00:03:13,240 So we're going to write a query here that will reach into our surveys collection inside of Mongo TV 47 00:03:13,630 --> 00:03:18,610 and pull out all the different surveys that have been created by the current user. 48 00:03:18,610 --> 00:03:22,480 So before we write out the actual query just a couple of quick reminders. 49 00:03:22,480 --> 00:03:30,160 First off recall that the current user is available on the wreck object right here as rec dot user. 50 00:03:30,160 --> 00:03:34,510 So we want to figure out who the current user is just reference red user. 51 00:03:34,630 --> 00:03:41,800 Secondly to figure out which surveys a user created we had previously when we put together the survey 52 00:03:41,800 --> 00:03:47,470 model we had said that every survey would have this underscore user property right here. 53 00:03:47,470 --> 00:03:54,100 And we said that this underscore user property would contain the ID of the user who had created a particular 54 00:03:54,100 --> 00:03:55,100 survey. 55 00:03:55,150 --> 00:04:01,060 So essentially to make sure that we only pull out the surveys that belong to a particular user We will 56 00:04:01,060 --> 00:04:09,210 ask mongoose to fetch all of our surveys where underscore ID is equal to the current user's ID. 57 00:04:09,340 --> 00:04:13,760 So let's go back to our survey route's file and write out the actual logic for for this. 58 00:04:13,960 --> 00:04:20,080 I think it's going look something like Survey dot find and so find will look into our collection of 59 00:04:20,080 --> 00:04:26,470 surveys and it will do a search and pull out all of the different records that meet some specific criteria 60 00:04:27,100 --> 00:04:34,380 and that criteria will be provided in the first argument to this query which is going to be an object. 61 00:04:34,450 --> 00:04:43,600 So we're going to say find all the surveys that have an underscore user property equal to rec user id 62 00:04:43,990 --> 00:04:46,600 like so OK. 63 00:04:46,620 --> 00:04:47,970 So this is pretty much the query. 64 00:04:47,970 --> 00:04:48,680 Just that simple. 65 00:04:48,680 --> 00:04:50,340 Not that bad right. 66 00:04:50,700 --> 00:04:54,630 Now one thing to keep in mind because remember there are still a couple of things we need to be on our 67 00:04:54,630 --> 00:04:57,510 toes about reaching out to the database. 68 00:04:57,600 --> 00:05:03,540 Asynchronous requests whenever we have asynchronous code we are making use of the async awaits helpers. 69 00:05:03,810 --> 00:05:10,560 So I'm going to say this list of surveys will be assigned to the variable surveys and because this is 70 00:05:10,560 --> 00:05:17,340 an asynchronous query we're going to market with the wait keyword and then because this function now 71 00:05:17,340 --> 00:05:23,910 contains an awaits reference or a wait key word will make sure that we mark the function as being a 72 00:05:23,910 --> 00:05:26,560 sync as well like so. 73 00:05:27,330 --> 00:05:27,650 OK. 74 00:05:27,690 --> 00:05:32,430 Now one other quick thing that we can very quickly fix in here as well and I'm just planning towards 75 00:05:32,430 --> 00:05:37,490 the feature future excuse me and thinking about all the different aspects of our application. 76 00:05:37,770 --> 00:05:43,930 Looking at the code inside this request handler it's clear that if someone is going to make requests 77 00:05:44,050 --> 00:05:50,670 to this API we really expect them to be logged in because we're referencing rechts user ID right here. 78 00:05:50,670 --> 00:05:57,850 So clearly if you want to to access this handler we want the person making the request to be authenticated. 79 00:05:57,930 --> 00:06:04,320 So we're going to reuse that require a log in Middleware that we put together way long ago to ensure 80 00:06:04,320 --> 00:06:06,610 that a user is authenticated. 81 00:06:06,960 --> 00:06:09,770 So remember how we wire up this middleware right here. 82 00:06:09,990 --> 00:06:14,910 We pass them the middleware as the second argument to our request handler. 83 00:06:14,910 --> 00:06:22,500 So after we specify the route we'll then say require log in put our comma in. 84 00:06:22,660 --> 00:06:27,690 So essentially whenever someone makes a request to this we make sure they're authenticated and then 85 00:06:27,690 --> 00:06:30,310 they can go off to the request body right here. 86 00:06:31,080 --> 00:06:31,470 OK. 87 00:06:31,500 --> 00:06:35,490 So now the very last thing that we want to take care of we want to make sure that after we have the 88 00:06:35,490 --> 00:06:41,610 list of surveys we then send a response back to whoever made this request and say hey here you go here's 89 00:06:41,610 --> 00:06:42,830 your list of surveys. 90 00:06:43,110 --> 00:06:51,220 So pretty straightforward we'll just say residents send surveys like so OK. 91 00:06:51,260 --> 00:06:54,760 So this this co-direct here is definitely going to work for our purposes. 92 00:06:54,920 --> 00:06:59,610 But there's one kind of loose end here that I want to remind you about. 93 00:06:59,780 --> 00:07:06,080 Remember that when we were just putting together our web hook and point right here we made a huge deal 94 00:07:06,380 --> 00:07:12,770 around this query around the fact that it did not have to load up the big list of recipients because 95 00:07:12,770 --> 00:07:18,290 that list of recipients can be tens of records long it can be hundreds of thousands actually tens of 96 00:07:18,290 --> 00:07:19,980 thousands records long. 97 00:07:20,030 --> 00:07:26,810 And so you can very quickly imagine inside of our new API slash cerveza handler if a given user has 98 00:07:26,810 --> 00:07:33,770 like 50 surveys and every survey has 10000 or 15000 recipients. 99 00:07:33,770 --> 00:07:40,440 Clearly we do not want to pull out all that information from our back end and send it down to our user. 100 00:07:40,440 --> 00:07:42,820 Any single response. 101 00:07:43,020 --> 00:07:49,730 And if you really think about it at all looking back at our markup for this feature the mockup itself 102 00:07:49,850 --> 00:07:56,300 doesn't really have any indication that we care about the individual recipient email addresses like 103 00:07:56,300 --> 00:08:01,980 there's clearly no reason to really send back the entire big list of recipients. 104 00:08:02,000 --> 00:08:09,200 So I think that when we pull out our list of surveys from our database we want to somehow tell mongoose 105 00:08:09,230 --> 00:08:16,190 and tell Mongo that when we get some response back from this query we do not want to also receive the 106 00:08:16,190 --> 00:08:19,880 big long list of recipients for every individual survey. 107 00:08:20,270 --> 00:08:25,610 Now we could certainly leave our code as is right now because as you and I are building this thing we 108 00:08:25,610 --> 00:08:32,500 never really have more than like you know five different e-mails associated with every survey. 109 00:08:32,510 --> 00:08:37,350 So in theory right now we definitely believe our code like this and be totally happy with it. 110 00:08:37,550 --> 00:08:42,290 But again I'm kind of thinking to the future and I'm thinking about when people start really heavily 111 00:08:42,290 --> 00:08:43,570 using our application. 112 00:08:43,670 --> 00:08:50,420 We don't want to accidentally ship down like tens of megabytes of data inside a simple request handler 113 00:08:50,420 --> 00:08:51,790 like this one right here. 114 00:08:52,190 --> 00:08:53,790 So let's take a quick break. 115 00:08:53,810 --> 00:08:58,880 When we come back we're going to figure out how we can tell mongoose and Mongo that when it finds our 116 00:08:58,880 --> 00:09:04,960 list of surveys we do not want to get the list of recipients inside of each survey. 117 00:09:05,000 --> 00:09:08,270 So let's take a quick break and tackle that challenge in the next section.