1 00:00:03,650 --> 00:00:06,795 Now that we have completed implementing 2 00:00:06,795 --> 00:00:11,395 the REST API server using Express and MongoDB in this course, 3 00:00:11,395 --> 00:00:14,990 the next immediate thought that might occur in your mind is, 4 00:00:14,990 --> 00:00:20,490 since we have already developed the client applications in the previous courses, 5 00:00:20,490 --> 00:00:24,930 how do we integrate the two together so that our client application is able to 6 00:00:24,930 --> 00:00:30,880 interact with the full-fledged REST API server that we have developed in this course? 7 00:00:30,880 --> 00:00:33,820 So, this is what we will examine in 8 00:00:33,820 --> 00:00:39,820 this lecture and the two exercises that follow this lecture. 9 00:00:39,820 --> 00:00:41,770 So, at the end of this lesson, 10 00:00:41,770 --> 00:00:44,390 you will have React Client that will be 11 00:00:44,390 --> 00:00:47,330 able to communicate with the server that you have just developed in 12 00:00:47,330 --> 00:00:50,345 this course and be able to support 13 00:00:50,345 --> 00:00:56,510 the full-fledged client side view of our entire application. 14 00:00:56,510 --> 00:00:58,970 So that way we will see that we have developed 15 00:00:58,970 --> 00:01:02,565 the complete end to end 16 00:01:02,565 --> 00:01:07,795 application from the client side all the way to the server side in this course. 17 00:01:07,795 --> 00:01:10,910 To integrate the client and the server, 18 00:01:10,910 --> 00:01:13,670 as we have realized our server is already 19 00:01:13,670 --> 00:01:17,525 implemented to support the full-fledged REST API. 20 00:01:17,525 --> 00:01:19,220 From our client side, 21 00:01:19,220 --> 00:01:20,720 whether it is the angular client, 22 00:01:20,720 --> 00:01:23,340 the ionic client or the native script client, 23 00:01:23,340 --> 00:01:28,240 they all interact with the server using the REST API endpoints. 24 00:01:28,240 --> 00:01:33,630 So, when the client sends the request to the server at the REST API endpoint, 25 00:01:33,630 --> 00:01:38,190 the server will respond with the corresponding JSON data back to the client. 26 00:01:38,190 --> 00:01:44,225 The client can then make use of the JSON data to render the views for the user. 27 00:01:44,225 --> 00:01:50,450 So, given this understanding of the communication between the client and the server, 28 00:01:50,450 --> 00:01:53,745 the integration should be fairly straightforward. 29 00:01:53,745 --> 00:01:58,475 Now that we have the user authentication built into our server side, 30 00:01:58,475 --> 00:02:03,330 we need to retrofit our client applications to 31 00:02:03,330 --> 00:02:08,400 enable them to do userauthentication on the server side 32 00:02:08,400 --> 00:02:12,200 by posting the login information to the server an then 33 00:02:12,200 --> 00:02:16,010 obtaining the authentication token from 34 00:02:16,010 --> 00:02:19,120 the server side and thereafter communicating with the server 35 00:02:19,120 --> 00:02:23,700 including the authentication token in the header of the request messages. 36 00:02:23,700 --> 00:02:27,050 So, all this means that we need to do minor adjustments both to 37 00:02:27,050 --> 00:02:31,345 the client and the server so that the two can communicate with each other. 38 00:02:31,345 --> 00:02:36,530 One aspect that I haven't dealt with in the exercise earlier 39 00:02:36,530 --> 00:02:41,970 is how the server will handle the query parameters that come in from the client side. 40 00:02:41,970 --> 00:02:43,480 So, as we realized, 41 00:02:43,480 --> 00:02:47,450 when the client side sends a request for 42 00:02:47,450 --> 00:02:53,035 a featured dish or a featured leader or a featured promotion, 43 00:02:53,035 --> 00:02:55,910 we saw that the URL includes, 44 00:02:55,910 --> 00:02:59,590 dishes question mark feature is equal to 45 00:02:59,590 --> 00:03:04,370 true in the request URL that comes from the client side. 46 00:03:04,370 --> 00:03:07,210 Now, in the data on the server side, 47 00:03:07,210 --> 00:03:09,585 we already saw that the dish, 48 00:03:09,585 --> 00:03:15,370 the promotion or the leader includes the featured flag already in the JSON data. 49 00:03:15,370 --> 00:03:18,649 So, when this request comes to the server side, 50 00:03:18,649 --> 00:03:21,394 then the server should be able to extract 51 00:03:21,394 --> 00:03:26,765 this query parameter from the incoming request and then 52 00:03:26,765 --> 00:03:32,390 appropriately do the query of 53 00:03:32,390 --> 00:03:39,950 the MongoDB and then obtain only the results where this featured flag is set to true. 54 00:03:39,950 --> 00:03:41,740 So, to do that as we saw, 55 00:03:41,740 --> 00:03:47,075 the URL that is used for sending the request to the server is, 56 00:03:47,075 --> 00:03:52,030 slash dishes question mark featured is equal to true. 57 00:03:52,030 --> 00:03:57,905 So, that is how we will supply the query parameters to our server side. 58 00:03:57,905 --> 00:04:02,610 Now in addition, when this information is received on the server side, 59 00:04:02,610 --> 00:04:07,430 now we saw that earlier when we did the get request on the server side, 60 00:04:07,430 --> 00:04:10,190 we simply said dishes find and then we would find 61 00:04:10,190 --> 00:04:13,135 all the dishes and then return them when 62 00:04:13,135 --> 00:04:19,745 the get request is sent to the dish router route slash. 63 00:04:19,745 --> 00:04:25,185 The same logic applies both to the promo router as well as to the leader router. 64 00:04:25,185 --> 00:04:30,339 Now, when you include a query parameter like that in the URL, 65 00:04:30,339 --> 00:04:34,695 how will our server side be able to extract this query parameter? 66 00:04:34,695 --> 00:04:35,980 So, this is where, 67 00:04:35,980 --> 00:04:42,590 when the incoming request has this query parameter attached to the incoming URL, 68 00:04:42,590 --> 00:04:47,375 the express server will automatically process that and turn that into 69 00:04:47,375 --> 00:04:54,445 a JSON object that is loaded onto a request message coming in on the server side. 70 00:04:54,445 --> 00:05:00,710 Now, this is available on the server side in the form of req.query. 71 00:05:00,710 --> 00:05:06,545 So, whatever query parameters you include in the URL will be turned into 72 00:05:06,545 --> 00:05:11,480 corresponding JSON objects with the information set as 73 00:05:11,480 --> 00:05:16,880 shown here and then loaded onto the request object on the server side. 74 00:05:16,880 --> 00:05:19,940 So, by using req.query on the server side, 75 00:05:19,940 --> 00:05:23,625 we will be able to obtain these query parameters. 76 00:05:23,625 --> 00:05:27,935 So, when you perform a get request on the server side you say 77 00:05:27,935 --> 00:05:34,115 dishes.find and then you include the req.query into the find there. 78 00:05:34,115 --> 00:05:38,960 So thereby, when the MongoDB is 79 00:05:38,960 --> 00:05:44,120 queried then only those records or only those documents for 80 00:05:44,120 --> 00:05:50,390 which the featured is set to true will be extracted from the MongoDB and supplied back to 81 00:05:50,390 --> 00:05:57,020 us within this get method here and then can be returned to the client side. 82 00:05:57,020 --> 00:06:05,270 So, this is as simple as that in handling the query parameters on our server side. 83 00:06:05,270 --> 00:06:10,645 So, this update we will do to both the dish router, 84 00:06:10,645 --> 00:06:16,880 the promo router, and the leader router on our server side. 85 00:06:16,880 --> 00:06:18,430 The next part is, 86 00:06:18,430 --> 00:06:20,545 of course, User Authentication. 87 00:06:20,545 --> 00:06:22,060 So, as we have realized, 88 00:06:22,060 --> 00:06:24,150 on the server side we already have 89 00:06:24,150 --> 00:06:29,450 these REST API endpoints which are useful for User Authentication, 90 00:06:29,450 --> 00:06:33,260 in particular when you do a post to slash users 91 00:06:33,260 --> 00:06:37,100 slash login with the username and password, 92 00:06:37,100 --> 00:06:41,675 then you will be able to authenticate the user on the server side. 93 00:06:41,675 --> 00:06:46,080 Now, when the user is authenticated on the server-side successfully, 94 00:06:46,080 --> 00:06:50,584 then the reply message coming from the server side will include 95 00:06:50,584 --> 00:06:58,880 the JSON Web Token in the reply body of the incoming reply message from the server side. 96 00:06:58,880 --> 00:07:00,350 So, on the client side, 97 00:07:00,350 --> 00:07:04,700 we should be able to extract this token and then use this token subsequently. 98 00:07:04,700 --> 00:07:08,210 So, when the client receives the reply message from 99 00:07:08,210 --> 00:07:12,560 the server side and the user is successfully authenticated on the server side, 100 00:07:12,560 --> 00:07:15,220 the reply message will contain the JSON Web Token, 101 00:07:15,220 --> 00:07:16,950 which has to be extracted, 102 00:07:16,950 --> 00:07:20,780 and thereafter the client should include this JSON Web Token in 103 00:07:20,780 --> 00:07:26,200 the authorization header for every outgoing request from the client side. 104 00:07:26,200 --> 00:07:31,205 This is accomplished by saving the JSON Web Token to the local storage. 105 00:07:31,205 --> 00:07:35,155 Thereafter, for every fetch requests that we issue, 106 00:07:35,155 --> 00:07:40,365 we can set up the authorization header to contain the JSON Web Token. 107 00:07:40,365 --> 00:07:43,815 Now, the logout process is fairly straightforward, 108 00:07:43,815 --> 00:07:47,865 if we destroy the JSON Web Token that we have on the client side, 109 00:07:47,865 --> 00:07:51,210 then the client will no longer be able to the access the server. 110 00:07:51,210 --> 00:07:53,930 So, it is as simple as just destroying 111 00:07:53,930 --> 00:07:58,180 the JSON Web Token on the client side for logging out that client. 112 00:07:58,180 --> 00:08:00,530 So, given this understanding, 113 00:08:00,530 --> 00:08:04,175 let's see the steps that are involved in 114 00:08:04,175 --> 00:08:09,840 doing the user authentication on handling the user authentication on the client side. 115 00:08:09,840 --> 00:08:13,085 So, to handle the user authentication on the client side, 116 00:08:13,085 --> 00:08:19,000 the client will send a post request to the slash users slash login endpoint, 117 00:08:19,000 --> 00:08:24,190 and the body of the post request will contain the username and password. 118 00:08:24,190 --> 00:08:26,720 We are using the login authentication in this case. 119 00:08:26,720 --> 00:08:28,695 Now, for Facebook authentication, again, 120 00:08:28,695 --> 00:08:32,425 that is a different setup that I'm not going to discuss right now. 121 00:08:32,425 --> 00:08:35,570 But the request body as you see for 122 00:08:35,570 --> 00:08:38,780 local authentication will contain the username and password. 123 00:08:38,780 --> 00:08:43,220 So, when the user is successfully authenticated on the server side, 124 00:08:43,220 --> 00:08:46,460 the server will then reply back to 125 00:08:46,460 --> 00:08:51,490 the client by including the JSON Web Token in the reply message. 126 00:08:51,490 --> 00:08:56,150 So, when the client receives the reply message from the server side, 127 00:08:56,150 --> 00:09:00,320 then the client will have to capture this JSON Web Token and then 128 00:09:00,320 --> 00:09:05,080 save the JSON Web Token into the local storage on the client side. 129 00:09:05,080 --> 00:09:11,300 Thereafter, the client should include this token in every outgoing request. 130 00:09:11,300 --> 00:09:14,495 So, how is this accomplished on the client side? 131 00:09:14,495 --> 00:09:20,285 First and foremost, we need to save the JSON Web Token into the local storage. 132 00:09:20,285 --> 00:09:25,670 Now, this is accomplished inside the action creator that handles the user login process. 133 00:09:25,670 --> 00:09:32,685 So, when the post is done to the server from the client side induction creator, 134 00:09:32,685 --> 00:09:36,020 then the reply message will contain the token, 135 00:09:36,020 --> 00:09:41,540 and this token is saved in the action creator that handles the user login process. 136 00:09:41,540 --> 00:09:45,875 Now thereafter, when any fetch request is done, 137 00:09:45,875 --> 00:09:52,829 then we can easily set the authorization header in the outgoing fetch request. 138 00:09:52,829 --> 00:09:56,005 Now, once the client logs out, 139 00:09:56,005 --> 00:09:59,930 the JSON Web Token will be destroyed on the client side. 140 00:09:59,930 --> 00:10:03,050 So thereafter, outgoing requests will not contain 141 00:10:03,050 --> 00:10:07,490 the JSON Web Token anymore because the JSON Web Token doesn't exist on the client side. 142 00:10:07,490 --> 00:10:10,790 So thereby, the user loses the authentication. 143 00:10:10,790 --> 00:10:17,455 So, that is how we will be handling the login and the logout process on the client side. 144 00:10:17,455 --> 00:10:21,890 By communicating with the server and then obtain the JSON Web Token and 145 00:10:21,890 --> 00:10:26,185 then including the JSON Web Token in every outgoing request. 146 00:10:26,185 --> 00:10:31,570 Now, with this understanding of how the client and the server will interact, 147 00:10:31,570 --> 00:10:35,540 let's now proceed to the next two exercises. 148 00:10:35,540 --> 00:10:40,410 First, we will update the server side with a few additions so 149 00:10:40,410 --> 00:10:45,550 that it can integrate well with our client side. 150 00:10:45,550 --> 00:10:50,075 Thereafter, we will update the client side or rather I will give you 151 00:10:50,075 --> 00:10:54,200 a full-fledged client application that I have taken 152 00:10:54,200 --> 00:10:58,875 from the earlier react force and adapted it, updated it. 153 00:10:58,875 --> 00:11:03,080 So, we will deal with both these in the next two exercises, 154 00:11:03,080 --> 00:11:09,460 and at the end of it you will understand how to integrate your client and server side.