Would you like to inspect the original subtitles? These are the user uploaded subtitles that are being translated: 1 1 00:00:01,220 --> 00:00:03,730 In this video, let's create a special type 2 2 00:00:03,730 --> 00:00:06,333 of middleware called param middleware. 3 3 00:00:07,920 --> 00:00:11,460 So param middleware is middleware that only runs 4 4 00:00:11,460 --> 00:00:13,940 for certain parameters, so basically, 5 5 00:00:13,940 --> 00:00:17,450 when we have a certain parameter in our URL. 6 6 00:00:17,450 --> 00:00:20,000 Now in our example here, the only parameter 7 7 00:00:20,000 --> 00:00:25,000 that we might have in our route URL is the id, right? 8 8 00:00:25,320 --> 00:00:28,120 And so we can write middleware that only runs 9 9 00:00:28,120 --> 00:00:31,100 when this id is present in the URL, 10 10 00:00:31,100 --> 00:00:34,570 okay, so let me show you how to do it. 11 11 00:00:34,570 --> 00:00:38,000 It is quite simple actually, so it's on our router 12 12 00:00:39,690 --> 00:00:43,260 and then the param method, okay. 13 13 00:00:43,260 --> 00:00:46,210 And so here we specify first the parameter 14 14 00:00:46,210 --> 00:00:48,890 that we actually want to search for, 15 15 00:00:48,890 --> 00:00:50,900 so basically the parameter for which 16 16 00:00:50,900 --> 00:00:54,400 this middleware is gonna run, and it's called id, 17 17 00:00:54,400 --> 00:00:57,333 and then of course our actual middleware function. 18 18 00:00:59,060 --> 00:01:02,800 And as usual, we have access to the request 19 19 00:01:02,800 --> 00:01:05,070 and to the response object, and then 20 20 00:01:05,070 --> 00:01:07,350 senses a middleware function also 21 21 00:01:07,350 --> 00:01:10,300 to the next function, right? 22 22 00:01:10,300 --> 00:01:12,090 Now in a param middleware function, 23 23 00:01:12,090 --> 00:01:15,370 we actually get access to a fourth argument 24 24 00:01:15,370 --> 00:01:18,783 and that one is the value of the parameter in question. 25 25 00:01:20,280 --> 00:01:23,553 So we usually call that one val, which stands for value. 26 26 00:01:26,240 --> 00:01:28,720 And so now we can go ahead and simply log it 27 27 00:01:28,720 --> 00:01:30,650 to the console, just to take a look 28 28 00:01:30,650 --> 00:01:35,510 if this actually works, so let's say Tour id is 29 29 00:01:37,700 --> 00:01:40,410 and then id, right? 30 30 00:01:40,410 --> 00:01:43,840 Next up, we also have to call next, right? 31 31 00:01:43,840 --> 00:01:46,470 Because otherwise the request response cycle 32 32 00:01:46,470 --> 00:01:48,970 will get stuck in this middleware function 33 33 00:01:48,970 --> 00:01:51,630 and it's not gonna be able to move on 34 34 00:01:51,630 --> 00:01:54,570 to the next middleware in the stack, right? 35 35 00:01:54,570 --> 00:01:56,903 Which are gonna be these routes down here. 36 36 00:01:57,860 --> 00:02:01,563 All right, so let's give it a save and check it out now. 37 37 00:02:03,000 --> 00:02:05,260 And we want it to not for get all users 38 38 00:02:06,370 --> 00:02:10,100 but for get one Tour, right? 39 39 00:02:10,100 --> 00:02:11,940 Well let me show you first what happens 40 40 00:02:11,940 --> 00:02:16,940 if we do not have any id, okay, and so now, 41 41 00:02:17,020 --> 00:02:20,310 we don't see any log down in our console. 42 42 00:02:20,310 --> 00:02:22,870 But if I now sent the same request on this route 43 43 00:02:22,870 --> 00:02:26,843 where we have the id, let's see what happens then. 44 44 00:02:26,843 --> 00:02:29,610 Oh, it tells me that id is not defined, 45 45 00:02:29,610 --> 00:02:33,500 and indeed it's not id, so that was a stupid mistake. 46 46 00:02:33,500 --> 00:02:36,420 So it is val for value, right? 47 47 00:02:36,420 --> 00:02:39,710 So remember how I said that this value parameter 48 48 00:02:39,710 --> 00:02:41,500 is the one that will actually hold 49 49 00:02:41,500 --> 00:02:44,400 the value of the id parameter, and so of course 50 50 00:02:44,400 --> 00:02:46,930 that's the one that we need to then use here 51 51 00:02:46,930 --> 00:02:49,303 in order to get access to that id. 52 52 00:02:50,280 --> 00:02:53,580 So let's try that again, and now indeed 53 53 00:02:53,580 --> 00:02:56,990 we have Tour id is two, right? 54 54 00:02:56,990 --> 00:03:00,120 So that log came right from this function here. 55 55 00:03:00,120 --> 00:03:01,893 Now, what I also want to show you is that 56 56 00:03:01,893 --> 00:03:04,160 this middleware function is not going to 57 57 00:03:04,160 --> 00:03:07,003 run for any of the user routes. 58 58 00:03:08,963 --> 00:03:13,380 So let's say we call a user with a specific id, 59 59 00:03:13,380 --> 00:03:15,593 so let's go ahead and copy this one here, 60 60 00:03:16,770 --> 00:03:20,680 create a new request with an id, 61 61 00:03:20,680 --> 00:03:22,493 and let me actually save it also. 62 62 00:03:25,250 --> 00:03:30,240 So get user and save to user, and when I send it here 63 63 00:03:30,240 --> 00:03:32,340 we of course get our standard response of 64 64 00:03:32,340 --> 00:03:35,200 this route is not defined, but you also see 65 65 00:03:35,200 --> 00:03:38,210 that we have no log like we had before. 66 66 00:03:38,210 --> 00:03:41,800 And so that is of course because this middleware function 67 67 00:03:41,800 --> 00:03:44,940 is only specified in our tour router. 68 68 00:03:44,940 --> 00:03:48,280 So in this kind of local mini application, 69 69 00:03:48,280 --> 00:03:51,750 so again, that is the analogy that I like to make. 70 70 00:03:51,750 --> 00:03:53,960 So basically that each router is 71 71 00:03:53,960 --> 00:03:58,040 kind of a mini sub-application, one for each resource. 72 72 00:03:58,040 --> 00:04:02,210 And so since this middleware is only specified 73 73 00:04:02,210 --> 00:04:04,300 on this router, well then of course, 74 74 00:04:04,300 --> 00:04:06,680 it is only part of the middleware stack 75 75 00:04:06,680 --> 00:04:10,670 if we are actually inside of this sub-application. 76 76 00:04:10,670 --> 00:04:11,780 Makes sense? 77 77 00:04:11,780 --> 00:04:16,460 So let's suppose we have an incoming request on tours/id. 78 78 00:04:16,460 --> 00:04:20,110 So that request will then go through all these middleware, 79 79 00:04:20,110 --> 00:04:22,900 so first this middleware, then this one, 80 80 00:04:22,900 --> 00:04:26,190 then this middleware, then this one, 81 81 00:04:26,190 --> 00:04:28,700 so all of these are part of the middleware stack 82 82 00:04:28,700 --> 00:04:31,360 and then it will finally hit this middleware 83 83 00:04:31,360 --> 00:04:33,660 and since this is actually the route, 84 84 00:04:33,660 --> 00:04:36,650 it will then get into tourRouter middleware. 85 85 00:04:36,650 --> 00:04:40,830 Okay, and so from there it then goes right into 86 86 00:04:40,830 --> 00:04:43,823 this middleware, and so then this code will be run. 87 87 00:04:45,650 --> 00:04:48,830 And again, that's only because it has an id in the route. 88 88 00:04:48,830 --> 00:04:51,970 If not, well, then this would simply be ignored 89 89 00:04:51,970 --> 00:04:54,540 and it would move on right to the next middleware 90 90 00:04:54,540 --> 00:04:58,097 in the stack, so these down here, right? 91 91 00:04:58,097 --> 00:05:01,770 Cool, so that is how param middleware works; 92 92 00:05:01,770 --> 00:05:04,296 but for now it is not really that useful. 93 93 00:05:04,296 --> 00:05:06,170 But we can actually use it for 94 94 00:05:06,170 --> 00:05:08,430 a very practical use case here. 95 95 00:05:08,430 --> 00:05:11,670 So let's go to our handler functions here 96 96 00:05:11,670 --> 00:05:14,800 and you see that in all of the handler functions 97 97 00:05:14,800 --> 00:05:19,023 that actually use the id, we check if the id is valid. 98 98 00:05:20,080 --> 00:05:24,560 So we do it here in get tour, and we also do it 99 99 00:05:24,560 --> 00:05:29,470 in update tour, so here, and in delete tour. 100 100 00:05:29,470 --> 00:05:32,250 So all these three functions have this very similar code 101 101 00:05:32,250 --> 00:05:34,370 where they check if the id is valid 102 102 00:05:34,370 --> 00:05:38,010 and if not, they send back this Invalid ID response. 103 103 00:05:38,010 --> 00:05:40,360 So we have all this code in the same place 104 104 00:05:40,360 --> 00:05:43,100 and as you already know, it is not a good practice 105 105 00:05:43,100 --> 00:05:46,020 to repeat code and so what we can do here 106 106 00:05:46,020 --> 00:05:48,750 is to use the concept of param middleware; 107 107 00:05:48,750 --> 00:05:51,680 and perform this check here in an outside middleware 108 108 00:05:51,680 --> 00:05:53,660 that it's gonna run before the request 109 109 00:05:53,660 --> 00:05:56,483 even hits these handler functions. 110 110 00:05:57,690 --> 00:06:01,010 So let's go ahead and copy or actually cut 111 111 00:06:01,010 --> 00:06:04,761 the code from here and create a new middleware function 112 112 00:06:04,761 --> 00:06:09,761 called checkID, and of course I also need to export that. 113 113 00:06:14,010 --> 00:06:18,344 So checkID and we have access, request, response, 114 114 00:06:18,344 --> 00:06:21,980 next, and again, keep in mind that 115 115 00:06:21,980 --> 00:06:25,150 it is a param middleware and so the fourth argument 116 116 00:06:25,150 --> 00:06:27,353 will be the value of the parameter. 117 117 00:06:29,040 --> 00:06:32,090 Okay, paste it here, and then don't forget 118 118 00:06:32,090 --> 00:06:36,570 to call next at the end of the middleware, all right? 119 119 00:06:36,570 --> 00:06:38,650 And what's also very important is that 120 120 00:06:38,650 --> 00:06:41,402 we have this return statement here, 121 121 00:06:41,402 --> 00:06:44,010 because if we didn't have this return here, 122 122 00:06:44,010 --> 00:06:47,360 well, then express would send this response back 123 123 00:06:47,360 --> 00:06:48,930 but it would still continue running 124 124 00:06:48,930 --> 00:06:50,550 the code in this function. 125 125 00:06:50,550 --> 00:06:52,510 And so after sending the response, 126 126 00:06:52,510 --> 00:06:55,170 it will then still hit this next function 127 127 00:06:55,170 --> 00:06:57,670 and it would move on to the next middleware 128 128 00:06:57,670 --> 00:07:00,560 and will then send another response to the client. 129 129 00:07:00,560 --> 00:07:02,500 But that is really not allowed, 130 130 00:07:02,500 --> 00:07:05,930 so remember that we actually run into this error before, 131 131 00:07:05,930 --> 00:07:08,150 where it told us that we were not allowed 132 132 00:07:08,150 --> 00:07:11,520 to send headers after the response had already been sent. 133 133 00:07:11,520 --> 00:07:13,030 And so that's the kind of error 134 134 00:07:13,030 --> 00:07:14,990 that we would run into if we didn't 135 135 00:07:14,990 --> 00:07:17,380 have this return statement, okay. 136 136 00:07:17,380 --> 00:07:20,880 So again, just make sure that after sending this response, 137 137 00:07:20,880 --> 00:07:23,460 the function will return so that it will finish 138 138 00:07:23,460 --> 00:07:26,350 and it will never call this next. 139 139 00:07:26,350 --> 00:07:28,350 So never forget that, but of course 140 140 00:07:28,350 --> 00:07:30,010 we're gonna do this multiple times 141 141 00:07:30,010 --> 00:07:31,720 throughout the rest of the course 142 142 00:07:31,720 --> 00:07:34,823 and so you will get used to this kind of pattern. 143 143 00:07:36,096 --> 00:07:39,570 So let's go ahead and remove this repeated code 144 144 00:07:39,570 --> 00:07:41,230 from all of these other functions 145 145 00:07:44,756 --> 00:07:47,197 so here we have it again, and yeah. 146 146 00:07:49,740 --> 00:07:52,352 I also want this code here just to make sure 147 147 00:07:52,352 --> 00:07:54,903 that the function's actually running, 148 148 00:07:57,910 --> 00:08:02,510 and okay, so now we can get rid of this here 149 149 00:08:02,510 --> 00:08:06,640 and replace it with our newly created controller function. 150 150 00:08:06,640 --> 00:08:07,990 So tourController, checkID, 151 151 00:08:11,550 --> 00:08:13,143 so let's check that out now, 152 152 00:08:15,180 --> 00:08:18,370 and well again, just to make sure 153 153 00:08:18,370 --> 00:08:19,860 that it doesn't run where we 154 154 00:08:19,860 --> 00:08:24,350 do not have an id, so we have no log here, 155 155 00:08:24,350 --> 00:08:27,810 so everything is still working on that side. 156 156 00:08:27,810 --> 00:08:30,670 And now get tour with a regular id, 157 157 00:08:30,670 --> 00:08:33,883 so a valid id, and so let's see. 158 158 00:08:34,750 --> 00:08:38,040 Well, we get the Tour id is log, 159 159 00:08:38,040 --> 00:08:40,346 and so that means if it did actually run 160 160 00:08:40,346 --> 00:08:43,563 our checkID middleware, right? 161 161 00:08:44,560 --> 00:08:46,986 And if we now try an invalid id, 162 162 00:08:46,986 --> 00:08:50,090 well then we get our Invalid ID message, 163 163 00:08:50,090 --> 00:08:54,803 the 404 error code, and of course our tour id. 164 164 00:08:56,200 --> 00:08:58,930 Let's do the same with the patch, 165 165 00:08:58,930 --> 00:09:01,240 we already have an invalid ID here 166 166 00:09:01,240 --> 00:09:04,740 and so it also runs on this one. 167 167 00:09:04,740 --> 00:09:08,420 So, perfect, right? 168 168 00:09:08,420 --> 00:09:11,865 So we no longer have the checkID code 169 169 00:09:11,865 --> 00:09:15,910 in the update handler that we just invoked basically, 170 170 00:09:15,910 --> 00:09:18,240 but still our ID is checked because 171 171 00:09:18,240 --> 00:09:21,470 we have that middleware, so this here. 172 172 00:09:21,470 --> 00:09:23,630 We have that middleware in the stack 173 173 00:09:23,630 --> 00:09:26,750 before it actually hits the update tourController. 174 174 00:09:26,750 --> 00:09:30,200 So this middleware is now part of our pipeline 175 175 00:09:30,200 --> 00:09:32,770 as you can imagine it, now you might argue 176 176 00:09:32,770 --> 00:09:35,340 that we might simply create a simple function 177 177 00:09:35,340 --> 00:09:37,530 which could also check for the ID 178 178 00:09:37,530 --> 00:09:40,220 and I call that function inside of 179 179 00:09:40,220 --> 00:09:43,910 each of these tour function, and then call it inside 180 180 00:09:43,910 --> 00:09:47,830 each of these relevant tour controllers; 181 181 00:09:47,830 --> 00:09:49,410 but that would really go against 182 182 00:09:49,410 --> 00:09:52,860 the philosophy of express, where we should always work 183 183 00:09:52,860 --> 00:09:55,730 with the middleware stack, so with this pipeline 184 184 00:09:55,730 --> 00:10:00,010 as much as we can, okay, and so these functions here, 185 185 00:10:00,010 --> 00:10:02,850 they do not have to worry at all about validation. 186 186 00:10:02,850 --> 00:10:05,580 Each of these functions has only one purpose 187 187 00:10:05,580 --> 00:10:07,540 which is to do what they say, 188 188 00:10:07,540 --> 00:10:09,200 so this one just gets the tour, 189 189 00:10:09,200 --> 00:10:12,170 this one just creates a tour, this one just updates, 190 190 00:10:12,170 --> 00:10:14,650 and this one just deletes, it doesn't check, 191 191 00:10:14,650 --> 00:10:17,003 it doesn't have to worry about any of that. 192 192 00:10:18,910 --> 00:10:21,060 And if we would now add another controller here 193 193 00:10:21,060 --> 00:10:24,630 also depending on the id, well then that would automatically 194 194 00:10:24,630 --> 00:10:27,380 also check if the id is invalid 195 195 00:10:27,380 --> 00:10:30,960 without us having to do any additional steps. 196 196 00:10:30,960 --> 00:10:34,620 So this automatically will check for the id 197 197 00:10:34,620 --> 00:10:38,670 and so that's really handy and also how 198 198 00:10:38,670 --> 00:10:41,450 express apps should work, great. 199 199 00:10:41,450 --> 00:10:45,810 So we have another tool in our express toolbox that 200 200 00:10:45,810 --> 00:10:49,493 we can now use in order to write our express applications. 17911