WEBVTT 00:03.940 --> 00:04.420 Hey there. 00:04.420 --> 00:05.470 Everyone had a share. 00:05.470 --> 00:07.180 And in this video we're going to see that. 00:07.180 --> 00:11.440 What are the issues that we are about to face while registering a user? 00:11.680 --> 00:12.730 So this is all done. 00:12.730 --> 00:14.320 Our modeling and everything is done. 00:14.320 --> 00:16.510 Our DOT and V files are coming up nicely. 00:16.510 --> 00:20.560 But now let's go back and see that how the registration process actually works. 00:20.560 --> 00:24.850 And I'll give you this presentation because there are so many strategies being written up here. 00:24.970 --> 00:29.890 So while registering the user, these are all the steps that we have to take first, get all the information. 00:29.890 --> 00:31.510 So what are the user is sending it? 00:31.510 --> 00:36.700 We need to just accept that whether it's coming up in JSON form data, whatever that is majorly, it 00:36.700 --> 00:42.150 will be coming up in the JSON and then we have to check whether the mandatory fields are there or not. 00:42.160 --> 00:44.980 Now, this brings the question that can we send it via mongoose? 00:44.980 --> 00:45.970 Yes, of course. 00:45.970 --> 00:49.030 Can we send it on ourself by providing our validation? 00:49.030 --> 00:50.770 Yes, that is also possible. 00:50.980 --> 00:53.560 Now what about if the user is already registered? 00:53.560 --> 00:55.810 We need to take care of that situation as well. 00:55.840 --> 01:00.580 We need to also take care of password because storing the password into a clear text format, that is 01:00.580 --> 01:01.270 a no no. 01:01.270 --> 01:04.600 Nobody absolutely should do it ever in the case. 01:04.870 --> 01:10.000 And also, once the user is successfully registered, we have two strategies that we can follow, either 01:10.000 --> 01:15.100 to generate a token and give it to him so that he can access all the routes, or we can go ahead and 01:15.100 --> 01:19.150 send him a success message that, hey, everything was successful, now you can go ahead and log in. 01:19.150 --> 01:21.310 That's totally up to you which one you want to follow. 01:21.310 --> 01:24.160 There are multiple ways and there is no right or wrong here. 01:24.160 --> 01:26.740 So let's see at least what all we can do. 01:26.740 --> 01:30.400 Let's get all the information and check whether the fields are mandatory or not. 01:30.400 --> 01:34.750 And then we can check the already registered user, at least this much we can do. 01:34.750 --> 01:37.450 And then we're going to take care that what problem we are facing. 01:37.450 --> 01:40.900 So let's go ahead and let's write this one from the fresh. 01:40.900 --> 01:46.420 So we're going to say that app dot post, obviously some information is coming up on what route it will 01:46.420 --> 01:46.960 be coming up. 01:46.960 --> 01:49.060 Let's go ahead and design a route register. 01:51.070 --> 01:52.030 How to define that. 01:52.030 --> 01:53.650 Is it going to be registered or sign up? 01:53.660 --> 01:57.010 That is totally a call of the backend developer on the front end. 01:57.010 --> 02:01.330 You can make that out whatever you like, but at the end of the day, collecting that information and 02:01.330 --> 02:05.380 sending this route is the job of frontend developer, so feel free to call it anything that's totally 02:05.380 --> 02:11.230 up to your call or the strategies or the kind of structure that you're followed by the team itself. 02:11.590 --> 02:11.900 Okay. 02:11.920 --> 02:15.460 So we're going to go ahead and say this is the request and this is the response that we are going to 02:15.460 --> 02:15.950 get. 02:15.970 --> 02:16.810 There we go. 02:16.900 --> 02:20.290 Now, the first step is to grab all of the information. 02:20.290 --> 02:24.640 So we're going to go ahead and say that there will be a lot of information that is coming up like request, 02:24.640 --> 02:29.370 dot, body, dot, first name, request, body, dot, last name and all of that. 02:29.380 --> 02:36.070 So rather than calling it something like this and declaring available like something like first name 02:36.070 --> 02:40.390 is going to be request, dot, dot, first name rather we will be structuring it. 02:40.390 --> 02:45.430 So rather, let's go ahead and remove the first name like this and the structure like this. 02:45.430 --> 02:50.770 And now we can go ahead and say that, hey, this is first name, this is last name, this is going 02:50.770 --> 02:52.870 to be email password. 02:52.870 --> 02:55.990 And I guess these are only options that we are asking. 02:56.380 --> 02:58.450 Surely we never ask for token. 02:58.450 --> 03:02.800 We give the token, we generate the token and store that into the model itself. 03:02.890 --> 03:04.450 Okay, so this is all good. 03:04.450 --> 03:05.770 The step one is all done. 03:05.770 --> 03:07.810 Grab all the information from here. 03:07.810 --> 03:09.190 But there is the problem. 03:09.190 --> 03:13.150 Remember I told you Express cannot actually handle the JSON file directly. 03:13.150 --> 03:14.080 It cannot. 03:14.080 --> 03:15.850 It need to use a middleware for that. 03:15.850 --> 03:17.080 We already have seen that. 03:17.080 --> 03:23.620 So we need to design or write a middleware up here app dot use and there we have to say express JSON. 03:24.250 --> 03:29.470 Now this needs to be called at the very top, usually because these results are already being done and 03:29.470 --> 03:32.620 then are writing express JSON middleware, there is no point. 03:32.620 --> 03:34.000 So go ahead and do that. 03:34.000 --> 03:34.480 Okay. 03:34.660 --> 03:36.580 This part we have done, let's go ahead and see. 03:36.580 --> 03:40.780 So we have get all the information now we need to check whether the fields are mandatory. 03:41.020 --> 03:44.230 Now, a couple of things can be done up here at this point. 03:44.800 --> 03:49.630 You can go ahead and apply your own validation check or you can use the mongoose one. 03:49.630 --> 03:53.110 We haven't checked the mongoose one yet, so we're going to use our own. 03:53.110 --> 03:57.100 But at least let's take a look on what kind of validation we can put up. 03:57.100 --> 04:02.320 So if I go up in the validation and let's go ahead and see here so I can go ahead and say, hey, minimum 04:02.320 --> 04:03.730 six is required and all of that. 04:03.730 --> 04:08.380 So there is lot of example going up here and you can design your custom error message. 04:08.380 --> 04:14.230 So notice here we already discussed this that this is a main type and then we can say like for example, 04:14.230 --> 04:20.380 unique is true and if not true, then this is going to be the message that goes in and then we can go 04:20.380 --> 04:25.450 ahead and handle the error like this and we can simply say, Hey, we can go ahead and grab the error 04:25.450 --> 04:26.710 message and all of that. 04:27.160 --> 04:29.710 We will be doing it definitely, but not right now. 04:29.710 --> 04:31.450 This is a really simple validation. 04:31.450 --> 04:36.190 We can go ahead and check it all up by ourself just using a simple f and ls. 04:36.190 --> 04:39.910 So we need to check whether all the information is coming up or not. 04:39.910 --> 04:44.800 Remember, we haven't wrote this into the model that all the information is required, but we want all 04:44.800 --> 04:45.850 information from the user. 04:45.850 --> 04:51.190 So we're going to say that if email is there and if. 04:53.650 --> 04:54.940 Password is there. 04:54.970 --> 04:56.320 So come on, suggest me. 04:56.320 --> 04:57.700 No, no suggestion. 04:57.700 --> 04:58.420 Password. 04:58.420 --> 05:02.200 And then we are going to have first name and then we are going to have last name. 05:02.320 --> 05:05.650 So all these information and remember, we don't need to write a comma. 05:05.650 --> 05:09.250 We need to write an end because we are checking for all the fields. 05:11.890 --> 05:12.080 Okay. 05:12.500 --> 05:19.580 So all the fields are there and we're going to go ahead and wrap this up and then we're going to use 05:19.580 --> 05:24.560 an exclamation sign to say that if none of them is present, remember, there is no order in here. 05:24.560 --> 05:28.810 Remember, there is an end because I want to see that all information needs to come up here. 05:28.820 --> 05:33.050 Now, if there is an exclamation, that means none of the information came up, or at least one of them 05:33.050 --> 05:33.840 is missing. 05:33.860 --> 05:39.040 In that case, I'm going to go ahead and say it as status and here comes up your knowledge of status. 05:39.050 --> 05:45.020 So 400 would be a pretty good status quo to raise, but you can go more precise on that. 05:45.020 --> 05:48.070 And then we are going to go ahead and simply send a message. 05:48.080 --> 05:52.520 Now, message can be in the JSON format also, but we're going to pass on just a string because we are 05:52.520 --> 05:54.530 not standardized that much yet. 05:54.650 --> 05:56.090 That will come up in the next one. 05:56.090 --> 05:58.160 So we're going to say all fields. 05:59.530 --> 06:03.460 Are required, and again, make sure your message is as readable as possible. 06:04.150 --> 06:05.190 And one more thing. 06:05.200 --> 06:08.970 In this case, I don't need to say return resident status. 06:08.980 --> 06:09.760 You can actually. 06:09.760 --> 06:15.400 But as soon as the status is being returned, something like resident status has sent something. 06:15.400 --> 06:17.500 After that, the code is not going to execute. 06:17.500 --> 06:19.000 So make sure you keep an eye on that. 06:19.630 --> 06:20.500 So this is good. 06:20.500 --> 06:22.840 So we have checked whether all fields are coming in. 06:22.870 --> 06:25.750 You can go ahead and remove some of the fields if that doesn't bother you. 06:25.900 --> 06:28.780 Moving on to the strategy part, so we have checked the mandatory field. 06:28.780 --> 06:33.640 You can go ahead and use your own validation and told you this is all about how you are processing your 06:33.640 --> 06:34.180 data. 06:34.450 --> 06:37.240 Now take care of the already registered user. 06:37.810 --> 06:40.150 Now this is where comes up the query. 06:40.150 --> 06:41.380 So this is the query part. 06:41.380 --> 06:42.910 I want to find something. 06:42.910 --> 06:46.690 So in this case, I want to go ahead and use the find or find one. 06:46.690 --> 06:48.820 Whatever you like to use, it's totally up to you. 06:48.820 --> 06:50.320 They are kind of very similar. 06:50.320 --> 06:56.410 I want to use the find one method and I can provide some of the parameters that based on this parameter, 06:56.500 --> 06:59.110 go ahead and grab me some data. 06:59.170 --> 07:03.940 Now remember, if you want to immediately execute it, go ahead and just write iSCSI there. 07:03.940 --> 07:05.830 But we don't want to do that. 07:05.830 --> 07:08.770 We want to almost use similar that, but not exactly. 07:09.040 --> 07:10.930 So let's go ahead and say that. 07:11.050 --> 07:12.400 So we will be saying. 07:13.230 --> 07:15.360 Existing users. 07:15.360 --> 07:21.000 So this is my available name and I'm going to go ahead and say user and we don't have a user. 07:21.000 --> 07:22.080 That is the first problem. 07:22.080 --> 07:26.310 So let's go ahead and bring the user from where this user is going to come up. 07:26.760 --> 07:28.680 We're going to call this one as user. 07:28.680 --> 07:32.790 That user will be coming up from require. 07:33.510 --> 07:37.950 We'll be going one directory back and not one directory back. 07:37.950 --> 07:40.170 It's actually inside the model. 07:40.170 --> 07:44.850 So we can go ahead and say, I need to go into model and inside that auth. 07:44.970 --> 07:50.880 Now notice here again the thing that we are actually bringing up this user and we are calling it as 07:50.880 --> 07:53.280 capital you, that's totally up to you. 07:53.280 --> 07:55.410 You want to call it as lowercase user, that's fine. 07:55.410 --> 07:58.480 But usually the standard is calling it as capital U. 07:58.830 --> 08:02.610 Now let's go ahead and make a query because this is an object created from Mongoose. 08:02.610 --> 08:06.420 That's why you are able to run all the queries that we just saw in the documentation. 08:06.420 --> 08:10.170 So anything that you see there, you can actually go ahead and use that find and find. 08:10.170 --> 08:11.520 We're not pretty similar. 08:11.790 --> 08:15.360 Again, there are of differences between them, but this is not a course on MongoDB. 08:15.390 --> 08:18.660 I'll still use just one here, so I want to find one. 08:18.660 --> 08:23.310 And inside this you can pass on the parameter based on which you want to find the user. 08:23.430 --> 08:25.800 My parameter is just email. 08:25.830 --> 08:30.180 It is expected that you write something like this and pass on emails in this case e mail email. 08:30.300 --> 08:33.900 But you get the idea this is just a JavaScript syntactic sugar here. 08:34.290 --> 08:41.040 Now this is either going to find something based on this email that if there is something existing in 08:41.040 --> 08:45.630 the database or not, and then we are going with that, that is fine. 08:46.380 --> 08:50.970 Now we want to proceed further down if there is nothing inside there. 08:50.970 --> 08:54.510 But if something comes up in here, we want to just return a message in here. 08:54.510 --> 08:57.390 So let's go ahead and figure out all the case like this. 08:57.600 --> 08:58.620 So if. 08:59.760 --> 09:04.860 Existing user is there that obviously we want to return the status just like this. 09:04.860 --> 09:08.250 So we are going to copy this and paste this. 09:08.490 --> 09:15.720 So we're going to say something like 401 or a proper error and we are going to say something like this 09:16.080 --> 09:18.720 user already exist. 09:19.710 --> 09:20.940 Okay, that is nice. 09:21.540 --> 09:25.260 So we have also validated and checked whether the user already exists or not. 09:25.260 --> 09:28.230 Let's see what the strategy is saying further down the road. 09:28.230 --> 09:30.600 So we have checked for already registered user. 09:30.600 --> 09:31.830 Now take care of the password. 09:31.830 --> 09:33.210 How should I take care of the password? 09:33.210 --> 09:34.410 I have no idea on that. 09:34.440 --> 09:35.730 How to generate the token? 09:35.730 --> 09:36.720 Absolutely no idea. 09:36.720 --> 09:37.680 Send success message. 09:37.680 --> 09:39.120 Yes, that I can do. 09:39.390 --> 09:39.710 Okay. 09:39.720 --> 09:43.920 Moving further down the road, there are a couple of still problems that exist that we need to address 09:43.920 --> 09:44.550 this far. 09:44.550 --> 09:46.500 So far the code is absolutely okay. 09:46.500 --> 09:47.760 We are working on that. 09:47.880 --> 09:49.310 Now, a couple of interesting thing. 09:49.320 --> 09:52.380 First, we haven't yet connected to the database. 09:52.380 --> 09:54.840 We are writing all the models and functionality, all of that. 09:54.840 --> 09:55.590 That is okay. 09:55.590 --> 09:59.910 We can still continue to do that, but we haven't connected to database that we need to do in the next 09:59.910 --> 10:00.420 video. 10:00.420 --> 10:04.710 And after that we need to learn a little bit about how we can encrypt our password. 10:04.710 --> 10:10.530 What are the possible ways of encrypting the password, on what point we can encrypt these password? 10:10.530 --> 10:13.800 And also we need to learn a little bit about these token generation. 10:13.800 --> 10:16.410 So there is a little bit more of the theory that we need to study. 10:16.410 --> 10:19.440 But in the next video we'll learn how to connect with the database. 10:19.440 --> 10:22.290 And then from there onwards we are going to study the theory part. 10:22.290 --> 10:24.210 Let's go ahead and catch up in the next video.