Hey there.
Everyone had a share.
And in this video we're going to see that.
What are the issues that we are about to face while registering a user?
So this is all done.
Our modeling and everything is done.
Our DOT and V files are coming up nicely.
But now let's go back and see that how the registration process actually works.
And I'll give you this presentation because there are so many strategies being written up here.
So while registering the user, these are all the steps that we have to take first, get all the information.
So what are the user is sending it?
We need to just accept that whether it's coming up in JSON form data, whatever that is majorly, it
will be coming up in the JSON and then we have to check whether the mandatory fields are there or not.
Now, this brings the question that can we send it via mongoose?
Yes, of course.
Can we send it on ourself by providing our validation?
Yes, that is also possible.
Now what about if the user is already registered?
We need to take care of that situation as well.
We need to also take care of password because storing the password into a clear text format, that is
a no no.
Nobody absolutely should do it ever in the case.
And also, once the user is successfully registered, we have two strategies that we can follow, either
to generate a token and give it to him so that he can access all the routes, or we can go ahead and
send him a success message that, hey, everything was successful, now you can go ahead and log in.
That's totally up to you which one you want to follow.
There are multiple ways and there is no right or wrong here.
So let's see at least what all we can do.
Let's get all the information and check whether the fields are mandatory or not.
And then we can check the already registered user, at least this much we can do.
And then we're going to take care that what problem we are facing.
So let's go ahead and let's write this one from the fresh.
So we're going to say that app dot post, obviously some information is coming up on what route it will
be coming up.
Let's go ahead and design a route register.
How to define that.
Is it going to be registered or sign up?
That is totally a call of the backend developer on the front end.
You can make that out whatever you like, but at the end of the day, collecting that information and
sending this route is the job of frontend developer, so feel free to call it anything that's totally
up to your call or the strategies or the kind of structure that you're followed by the team itself.
Okay.
So we're going to go ahead and say this is the request and this is the response that we are going to
get.
There we go.
Now, the first step is to grab all of the information.
So we're going to go ahead and say that there will be a lot of information that is coming up like request,
dot, body, dot, first name, request, body, dot, last name and all of that.
So rather than calling it something like this and declaring available like something like first name
is going to be request, dot, dot, first name rather we will be structuring it.
So rather, let's go ahead and remove the first name like this and the structure like this.
And now we can go ahead and say that, hey, this is first name, this is last name, this is going
to be email password.
And I guess these are only options that we are asking.
Surely we never ask for token.
We give the token, we generate the token and store that into the model itself.
Okay, so this is all good.
The step one is all done.
Grab all the information from here.
But there is the problem.
Remember I told you Express cannot actually handle the JSON file directly.
It cannot.
It need to use a middleware for that.
We already have seen that.
So we need to design or write a middleware up here app dot use and there we have to say express JSON.
Now this needs to be called at the very top, usually because these results are already being done and
then are writing express JSON middleware, there is no point.
So go ahead and do that.
Okay.
This part we have done, let's go ahead and see.
So we have get all the information now we need to check whether the fields are mandatory.
Now, a couple of things can be done up here at this point.
You can go ahead and apply your own validation check or you can use the mongoose one.
We haven't checked the mongoose one yet, so we're going to use our own.
But at least let's take a look on what kind of validation we can put up.
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
six is required and all of that.
So there is lot of example going up here and you can design your custom error message.
So notice here we already discussed this that this is a main type and then we can say like for example,
unique is true and if not true, then this is going to be the message that goes in and then we can go
ahead and handle the error like this and we can simply say, Hey, we can go ahead and grab the error
message and all of that.
We will be doing it definitely, but not right now.
This is a really simple validation.
We can go ahead and check it all up by ourself just using a simple f and ls.
So we need to check whether all the information is coming up or not.
Remember, we haven't wrote this into the model that all the information is required, but we want all
information from the user.
So we're going to say that if email is there and if.
Password is there.
So come on, suggest me.
No, no suggestion.
Password.
And then we are going to have first name and then we are going to have last name.
So all these information and remember, we don't need to write a comma.
We need to write an end because we are checking for all the fields.
Okay.
So all the fields are there and we're going to go ahead and wrap this up and then we're going to use
an exclamation sign to say that if none of them is present, remember, there is no order in here.
Remember, there is an end because I want to see that all information needs to come up here.
Now, if there is an exclamation, that means none of the information came up, or at least one of them
is missing.
In that case, I'm going to go ahead and say it as status and here comes up your knowledge of status.
So 400 would be a pretty good status quo to raise, but you can go more precise on that.
And then we are going to go ahead and simply send a message.
Now, message can be in the JSON format also, but we're going to pass on just a string because we are
not standardized that much yet.
That will come up in the next one.
So we're going to say all fields.
Are required, and again, make sure your message is as readable as possible.
And one more thing.
In this case, I don't need to say return resident status.
You can actually.
But as soon as the status is being returned, something like resident status has sent something.
After that, the code is not going to execute.
So make sure you keep an eye on that.
So this is good.
So we have checked whether all fields are coming in.
You can go ahead and remove some of the fields if that doesn't bother you.
Moving on to the strategy part, so we have checked the mandatory field.
You can go ahead and use your own validation and told you this is all about how you are processing your
data.
Now take care of the already registered user.
Now this is where comes up the query.
So this is the query part.
I want to find something.
So in this case, I want to go ahead and use the find or find one.
Whatever you like to use, it's totally up to you.
They are kind of very similar.
I want to use the find one method and I can provide some of the parameters that based on this parameter,
go ahead and grab me some data.
Now remember, if you want to immediately execute it, go ahead and just write iSCSI there.
But we don't want to do that.
We want to almost use similar that, but not exactly.
So let's go ahead and say that.
So we will be saying.
Existing users.
So this is my available name and I'm going to go ahead and say user and we don't have a user.
That is the first problem.
So let's go ahead and bring the user from where this user is going to come up.
We're going to call this one as user.
That user will be coming up from require.
We'll be going one directory back and not one directory back.
It's actually inside the model.
So we can go ahead and say, I need to go into model and inside that auth.
Now notice here again the thing that we are actually bringing up this user and we are calling it as
capital you, that's totally up to you.
You want to call it as lowercase user, that's fine.
But usually the standard is calling it as capital U.
Now let's go ahead and make a query because this is an object created from Mongoose.
That's why you are able to run all the queries that we just saw in the documentation.
So anything that you see there, you can actually go ahead and use that find and find.
We're not pretty similar.
Again, there are of differences between them, but this is not a course on MongoDB.
I'll still use just one here, so I want to find one.
And inside this you can pass on the parameter based on which you want to find the user.
My parameter is just email.
It is expected that you write something like this and pass on emails in this case e mail email.
But you get the idea this is just a JavaScript syntactic sugar here.
Now this is either going to find something based on this email that if there is something existing in
the database or not, and then we are going with that, that is fine.
Now we want to proceed further down if there is nothing inside there.
But if something comes up in here, we want to just return a message in here.
So let's go ahead and figure out all the case like this.
So if.
Existing user is there that obviously we want to return the status just like this.
So we are going to copy this and paste this.
So we're going to say something like 401 or a proper error and we are going to say something like this
user already exist.
Okay, that is nice.
So we have also validated and checked whether the user already exists or not.
Let's see what the strategy is saying further down the road.
So we have checked for already registered user.
Now take care of the password.
How should I take care of the password?
I have no idea on that.
How to generate the token?
Absolutely no idea.
Send success message.
Yes, that I can do.
Okay.
Moving further down the road, there are a couple of still problems that exist that we need to address
this far.
So far the code is absolutely okay.
We are working on that.
Now, a couple of interesting thing.
First, we haven't yet connected to the database.
We are writing all the models and functionality, all of that.
That is okay.
We can still continue to do that, but we haven't connected to database that we need to do in the next
video.
And after that we need to learn a little bit about how we can encrypt our password.
What are the possible ways of encrypting the password, on what point we can encrypt these password?
And also we need to learn a little bit about these token generation.
So there is a little bit more of the theory that we need to study.
But in the next video we'll learn how to connect with the database.
And then from there onwards we are going to study the theory part.
Let's go ahead and catch up in the next video.