1 00:00:00,000 --> 00:00:05,340 Now that we have 2 00:00:05,340 --> 00:00:11,610 completed implementing the REST API server using Express and MongoDB in this course, 3 00:00:11,610 --> 00:00:14,990 the next immediate thought that might occur in your mind is, 4 00:00:14,990 --> 00:00:18,555 since we have already developed the client applications, 5 00:00:18,555 --> 00:00:21,460 whether it is the Angular application, the Ionic application, 6 00:00:21,460 --> 00:00:25,380 or the Native Script application in the previous courses, 7 00:00:25,380 --> 00:00:29,820 how do we integrate the two together so that our client application is able to 8 00:00:29,820 --> 00:00:35,780 interact with the full-fledge REST API server that we have developed in this course? 9 00:00:35,780 --> 00:00:39,605 So, this is what we will examine in this lesson, 10 00:00:39,605 --> 00:00:44,715 in this lecture, and the two exercises that follow this lecture. 11 00:00:44,715 --> 00:00:46,655 So, at the end of this lesson, 12 00:00:46,655 --> 00:00:49,295 you will have an Angular client that we'll be 13 00:00:49,295 --> 00:00:52,220 able to communicate with the server that you have just developed in 14 00:00:52,220 --> 00:00:55,265 this course and be able to support 15 00:00:55,265 --> 00:01:01,410 the full-fledged client side view of our entire application. 16 00:01:01,410 --> 00:01:03,860 So, that way, we will see that we have developed 17 00:01:03,860 --> 00:01:11,150 the complete end to end application from the client side all the way to the server side. 18 00:01:11,150 --> 00:01:13,895 A similar approach can also be used with 19 00:01:13,895 --> 00:01:17,290 your Ionic client or with your Native script client, 20 00:01:17,290 --> 00:01:20,430 given the fact that both Ionic and Native script have been 21 00:01:20,430 --> 00:01:24,420 developed with the Angular engine behind the scenes. 22 00:01:24,420 --> 00:01:31,100 So, carrying out a similar set of steps should be able to make your Ionic client and also 23 00:01:31,100 --> 00:01:35,240 your Native script client communicate with the Express 24 00:01:35,240 --> 00:01:40,295 plus MongoDB rest API server that we have developed in this course. 25 00:01:40,295 --> 00:01:43,415 To integrate the client and the server, 26 00:01:43,415 --> 00:01:44,810 as we have realized, 27 00:01:44,810 --> 00:01:50,020 our server is already implemented to support the full-fledged REST API. 28 00:01:50,020 --> 00:01:51,695 From our client side, 29 00:01:51,695 --> 00:01:53,240 whether it is the angular client, 30 00:01:53,240 --> 00:01:55,750 the ionic client or the native script client, 31 00:01:55,750 --> 00:02:00,740 they all interact with the server using the REST API endpoints. 32 00:02:00,740 --> 00:02:06,135 So, when the client sends the request to the server at the REST API endpoint, 33 00:02:06,135 --> 00:02:10,729 the server will respond with the corresponding JSON data back to the client, 34 00:02:10,729 --> 00:02:16,720 and the client can then make use of the JSON data to render the views for the user. 35 00:02:16,720 --> 00:02:22,970 So, given this understanding of the communication between the client and the server, 36 00:02:22,970 --> 00:02:25,780 the integration should be fairly straightforward. 37 00:02:25,780 --> 00:02:26,960 But, now of course, 38 00:02:26,960 --> 00:02:30,820 when we developed our Angular or the Ionic or the NativeScript client, 39 00:02:30,820 --> 00:02:34,990 we didn't do the full-fledged user authentication part, 40 00:02:34,990 --> 00:02:38,225 because we didn't have that in our JSON server. 41 00:02:38,225 --> 00:02:43,250 Now that we have the user authentication built into our server side, 42 00:02:43,250 --> 00:02:47,810 we need to retrofit our client applications to 43 00:02:47,810 --> 00:02:52,970 enable them to do user authentication on the server side, 44 00:02:52,970 --> 00:02:56,660 by posting the login information to the server and then 45 00:02:56,660 --> 00:03:01,190 obtaining the authentication token from the server side, 46 00:03:01,190 --> 00:03:04,400 and thereafter, communicating with the server including 47 00:03:04,400 --> 00:03:08,175 the authentication token in the header of the request messages. 48 00:03:08,175 --> 00:03:10,130 So, all this means that we need to do 49 00:03:10,130 --> 00:03:12,860 minor adjustments both to the client and the server, 50 00:03:12,860 --> 00:03:15,860 so that the two can communicate with each other. 51 00:03:15,860 --> 00:03:21,020 One aspect that I haven't dealt with in the exercise earlier, 52 00:03:21,020 --> 00:03:26,445 is how the server will handle the query parameters that come in from the client side. 53 00:03:26,445 --> 00:03:27,970 So, as we realized, 54 00:03:27,970 --> 00:03:31,925 when the client side sends a request for 55 00:03:31,925 --> 00:03:37,360 a featured dish or a featured leader or a feature promotion, 56 00:03:37,360 --> 00:03:41,665 we saw that the URL includes dishes, 57 00:03:41,665 --> 00:03:45,095 question mark feature is equal to true in 58 00:03:45,095 --> 00:03:48,840 the request URL that comes from the client side. 59 00:03:48,840 --> 00:03:51,670 Now, in the data on the server side, 60 00:03:51,670 --> 00:03:54,040 we already saw that the dish, 61 00:03:54,040 --> 00:03:56,090 the promotion or the leader, 62 00:03:56,090 --> 00:03:59,835 includes the feature flag already in the JSON data. 63 00:03:59,835 --> 00:04:02,975 So, when this request comes to the server side, 64 00:04:02,975 --> 00:04:10,285 then the server should be able to extract this query parameter from the incoming request, 65 00:04:10,285 --> 00:04:16,865 and then appropriately do the query of 66 00:04:16,865 --> 00:04:24,485 the MongoDB and then obtain only the results where this featured flag is set to true. 67 00:04:24,485 --> 00:04:26,365 So, to do that as we saw, 68 00:04:26,365 --> 00:04:36,380 the URL that is used for sending the request to the server is /dishes?feature=true. 69 00:04:36,380 --> 00:04:42,365 So, that is how we will supply the query parameters to our server side. 70 00:04:42,365 --> 00:04:47,510 Now, in addition, when this information is received on the server side, 71 00:04:47,510 --> 00:04:51,890 now, we saw that earlier when we did the get request on the server side, 72 00:04:51,890 --> 00:04:56,975 we simply said dishes find and then we would find all the dishes and then return them 73 00:04:56,975 --> 00:05:03,675 when the get request is sent to the dishRouterroute/. 74 00:05:03,675 --> 00:05:09,470 The same logic applies both to the promo router as well as to the leader router. 75 00:05:09,470 --> 00:05:14,805 Now, when you include a query parameter like that in the URL, 76 00:05:14,805 --> 00:05:19,270 how will our server side be able to extract this query parameter? 77 00:05:19,270 --> 00:05:22,730 So, this is where when the incoming request has 78 00:05:22,730 --> 00:05:27,055 this query parameter attached to the incoming URL, 79 00:05:27,055 --> 00:05:31,835 the express server will automatically process that and turn that into 80 00:05:31,835 --> 00:05:38,910 a JSON object that is loaded onto a request message coming in on the server side. 81 00:05:38,910 --> 00:05:45,185 Now, this is available on the server side in the form of req.query. 82 00:05:45,185 --> 00:05:49,665 So, whatever query parameters you include in the URL, 83 00:05:49,665 --> 00:05:56,860 will be turned into corresponding JSON objects with the information set as shown here, 84 00:05:56,860 --> 00:06:01,350 and then loaded onto the request object on the server side. 85 00:06:01,350 --> 00:06:04,670 So, by using req.query on the server side, 86 00:06:04,670 --> 00:06:08,105 we will be able to obtain these query parameters. 87 00:06:08,105 --> 00:06:11,840 So, when you perform a get request on the server side, 88 00:06:11,840 --> 00:06:18,635 you say dishes.find and then you include the req.query into the find there. 89 00:06:18,635 --> 00:06:25,040 So, thereby, when the MongoDB is queried, then, 90 00:06:25,040 --> 00:06:31,160 only those records or only those documents for which the featured is set to true will be 91 00:06:31,160 --> 00:06:38,270 extracted from the MongoDB and supplied back to us within this get method here, 92 00:06:38,270 --> 00:06:41,625 and then, can be returned to the client side. 93 00:06:41,625 --> 00:06:49,745 So, this is as simple as that in handling the query parameters on our server side. 94 00:06:49,745 --> 00:06:55,135 So, this update we will do to both the dish router, 95 00:06:55,135 --> 00:07:01,225 the promo router, and the leader router on our server side. 96 00:07:01,225 --> 00:07:04,880 The next part is of course, user authentication. 97 00:07:04,880 --> 00:07:07,530 So, as we have realized on the server side, 98 00:07:07,530 --> 00:07:11,095 we already have these REST API endpoints, 99 00:07:11,095 --> 00:07:13,780 which are useful for user authentication. 100 00:07:13,780 --> 00:07:18,855 In particular, when you do a post to /users/login, 101 00:07:18,855 --> 00:07:22,040 with the username and password, then, 102 00:07:22,040 --> 00:07:26,140 you will be able to authenticate the user on the server side. 103 00:07:26,140 --> 00:07:30,535 Now, when the user is authenticated on the server side successfully, 104 00:07:30,535 --> 00:07:35,059 then the reply message coming from the server side will include 105 00:07:35,059 --> 00:07:43,345 the JSON web token in the reply body of the incoming reply message from the server side. 106 00:07:43,345 --> 00:07:44,810 So, on the client side, 107 00:07:44,810 --> 00:07:49,210 we should be able to extract this token and then use this token subsequently. 108 00:07:49,210 --> 00:07:52,700 So, when the client receives the reply message from 109 00:07:52,700 --> 00:07:57,140 the server side and the user is successfully authenticated on the server side, 110 00:07:57,140 --> 00:07:59,690 the reply message will contain the JSON web token, 111 00:07:59,690 --> 00:08:02,290 which has to be extracted, and thereafter, 112 00:08:02,290 --> 00:08:05,240 the client should include this JSON web token in 113 00:08:05,240 --> 00:08:10,620 the authorization header for every outgoing request from the client side. 114 00:08:10,620 --> 00:08:13,585 So, how do we handle this whole set of operations? 115 00:08:13,585 --> 00:08:15,800 Now, this is where we will implement 116 00:08:15,800 --> 00:08:20,255 another service that will be used on our client side, 117 00:08:20,255 --> 00:08:21,720 in our Angular client, 118 00:08:21,720 --> 00:08:23,810 called the authentication service, 119 00:08:23,810 --> 00:08:30,185 and that is where we will handle the entire login and the logout operations. 120 00:08:30,185 --> 00:08:33,850 Now, the logout process is fairly straightforward but, 121 00:08:33,850 --> 00:08:37,840 if we destroy the JSON web token that we have on the client side, 122 00:08:37,840 --> 00:08:41,160 then the client will no longer be able to access the server. 123 00:08:41,160 --> 00:08:43,850 So, it is as simple as just destroying 124 00:08:43,850 --> 00:08:48,095 the JSON web token on the client side for logging out that client. 125 00:08:48,095 --> 00:08:50,460 So, given this understanding, 126 00:08:50,460 --> 00:08:54,110 let's see the steps that are involved in 127 00:08:54,110 --> 00:08:59,760 doing the user authentication and handling the user authentication on the client side. 128 00:08:59,760 --> 00:09:03,320 So, to handle the user authentication on the client side, 129 00:09:03,320 --> 00:09:08,945 the client will send a post request to the /users/login endpoint, 130 00:09:08,945 --> 00:09:14,110 and the body of the post request will contain the username and password. 131 00:09:14,110 --> 00:09:16,660 We are using the login authentication in this case. 132 00:09:16,660 --> 00:09:18,650 Now, for Facebook authentication again, 133 00:09:18,650 --> 00:09:22,355 that is a different setup that I'm not going to discuss right now. 134 00:09:22,355 --> 00:09:26,465 But, the request body as you'll see for local authentication, 135 00:09:26,465 --> 00:09:28,730 will contain the username and password. 136 00:09:28,730 --> 00:09:33,170 So, when the user is successfully authenticated on the server side, 137 00:09:33,170 --> 00:09:36,410 the server will then reply back to 138 00:09:36,410 --> 00:09:41,425 the client by including the JSON web token in the reply message. 139 00:09:41,425 --> 00:09:46,070 So, when the client receives the reply message from the server side, 140 00:09:46,070 --> 00:09:49,790 then the client will have to capture this JSON web token, 141 00:09:49,790 --> 00:09:55,025 and then save the JSON web token into the local storage on the client side. 142 00:09:55,025 --> 00:10:01,250 Thereafter, the client should include this token in every outgoing request. 143 00:10:01,250 --> 00:10:04,455 So, how is this accomplished on the client side? 144 00:10:04,455 --> 00:10:06,155 First and foremost, of course, 145 00:10:06,155 --> 00:10:11,980 you need to save the incoming JSON web token into the local storage, 146 00:10:11,980 --> 00:10:16,790 and that is done in the authentication service that we will implement on the client side. 147 00:10:16,790 --> 00:10:19,975 Now, for every outgoing request, 148 00:10:19,975 --> 00:10:22,850 the client will include this token into the header, 149 00:10:22,850 --> 00:10:27,100 the authorization header of the outgoing request. 150 00:10:27,100 --> 00:10:28,555 Now, how is this accomplished? 151 00:10:28,555 --> 00:10:33,935 So, this is where we're going to take the help of an HTTP interceptor, 152 00:10:33,935 --> 00:10:37,265 that the HTTPclient in Angular supports. 153 00:10:37,265 --> 00:10:39,675 So, with the HTTP interceptor, 154 00:10:39,675 --> 00:10:42,305 the interceptor allows us to intercept 155 00:10:42,305 --> 00:10:45,875 every outgoing request message or even 156 00:10:45,875 --> 00:10:50,010 intercept every incoming reply message if you so choose to. 157 00:10:50,010 --> 00:10:52,175 But in the Angular application, 158 00:10:52,175 --> 00:10:56,215 we're going to be implementing the request interceptor, 159 00:10:56,215 --> 00:10:59,540 which I will illustrate in the exercise later. 160 00:10:59,540 --> 00:11:02,460 In the HTTP request interceptor, 161 00:11:02,460 --> 00:11:04,375 when the request message is intercepted, 162 00:11:04,375 --> 00:11:09,915 every outgoing request message will be intercepted and then the JSON web token 163 00:11:09,915 --> 00:11:15,650 will be inserted into the authorization header of the request message. 164 00:11:15,650 --> 00:11:20,290 Then thereafter, the request message would be passed on to the server side. 165 00:11:20,290 --> 00:11:26,825 So, thereby every outgoing request after the user is authenticated on the server side, 166 00:11:26,825 --> 00:11:30,620 every outgoing request from the client side will carry 167 00:11:30,620 --> 00:11:35,590 the JSON web token in the authorization header of the outgoing request. 168 00:11:35,590 --> 00:11:38,600 Now, once the client logs out, 169 00:11:38,600 --> 00:11:42,595 the JSON web token will be destroyed on the client side. 170 00:11:42,595 --> 00:11:47,215 So, thereafter, outgoing requests will not contain the JSON web token anymore, 171 00:11:47,215 --> 00:11:50,160 because the JSON web token doesn't exist on the client side. 172 00:11:50,160 --> 00:11:53,240 So, thereby, the user loses the authentication. 173 00:11:53,240 --> 00:12:00,030 So, that is how we will be handling the login and logout process on the client side, 174 00:12:00,030 --> 00:12:02,290 by communicating with the server, 175 00:12:02,290 --> 00:12:04,225 and then obtain the JSON web token, 176 00:12:04,225 --> 00:12:08,845 and then including the JSON web token in every outgoing request. 177 00:12:08,845 --> 00:12:14,250 Now, with this understanding of how the client and the server will interact, 178 00:12:14,250 --> 00:12:18,205 let's now proceed to the next two exercises. 179 00:12:18,205 --> 00:12:22,540 First, we will update the server side with a few additions, 180 00:12:22,540 --> 00:12:28,220 so that it can integrate well with our client site. 181 00:12:28,220 --> 00:12:32,750 Thereafter, we will update the client side or rather I will give you 182 00:12:32,750 --> 00:12:36,215 a full-fledged client application that I have 183 00:12:36,215 --> 00:12:40,795 taken from the earlier Angular course and then I'll updated it, 184 00:12:40,795 --> 00:12:45,875 which also provides us with the ability to use HTTP interceptors 185 00:12:45,875 --> 00:12:51,595 on both the outgoing requests and the incoming reply messages. 186 00:12:51,595 --> 00:12:56,090 So, we will deal with both these in the next two exercises, 187 00:12:56,090 --> 00:12:58,370 and at the end of it, you will understand how to 188 00:12:58,370 --> 00:13:02,530 integrate your client and the server side.