Hey, did everyone share?
And in this video we're going to talk about modeling of the application, but before that, we should
know what we are building up.
So let's go ahead and talk a little bit on that.
Now, our major goal is to design an authentication system.
Now what this authentication system is protecting, we are not worried about that part.
Maybe it's an e-commerce store, maybe it's an AE application, or maybe it's just an API which nobody
can access.
If he's not logged in, maybe are using a GitHub searcher or something, anything like that.
Now, authentication system is not very complex.
It can be from the perspective of what you are designing, but on a very basic level it has just three
components.
It has a registered component, a login component and some restricted routes.
Now what does it mean by that?
A user will be able to register into your system by providing all the details that you're asking him
once he has successfully registered means he's into the database now.
Whenever he comes the next time, he don't need to provide all that information.
Rather, he can enter into our system by providing less information.
That less information can be just user name, password or email password.
However you are designing your application further down the road, there can be some restricted routes,
the routes that nobody all can access, routes that only logged in user can access.
Now, further down this road, authentication can also become some of the more complex system you might
want to go for authentication as well as some validation check as well.
For example, some routes can be open for everyone.
Some routes can be open only for admin, some route can be open for managers and some routes for users,
and some are not for all everyone.
So there is authentication as well as a little bit of the validation that can be done.
So again, it can be complex, but we'll keep it short.
Now in this one, since this is not a register model or a login model, we call this one as user because
that's all it is governing up.
So I don't expect you to just go ahead of me in this section because there's so much detail and so much
to talk up here, and we won't be using any of these models.
We will be using our same free mirror or any other such mind mapping application.
So go ahead and create a free one up here, the empty one, and we're going to go ahead and start with
this one.
So we're going to call this one as simply auth system.
There we go, if I can write that.
There we go.
So this is the old system that we are having.
Let's go ahead and move it up here.
Now, this old system or any application that you're designing, maybe it's an E commerce.
It might have other components, like there can be controllers, there can be routes and a whole bunch
of other things.
We're going to go very short in this one.
We won't be separating our controllers and everything routes, at least in this section later on for
sure.
But let's go ahead and add this one.
So in this one, obviously, we'll have a model route that a lot of modeling can be done.
And we don't need you as of now.
And further down the road in the model, we are going to have multiple models, maybe, maybe not sure.
So we're going to call this one as user.
That is fine now.
Okay, go back up here.
So now how can I scroll this?
Okay.
We can move this one here.
So once we have this model defined and we're going to call this user again, it's not usually called
as users, it's called as user because this is defined as how single entity will look like.
Again, these are recommendations.
Nobody's stopping you to call it as users, but it is recommended.
In fact, people will say that, hey, this should be something like user, but this is totally up to
you however you want to define it.
And usually models have first uppercase letter.
Now on top of that, once this is all done, I you can actually go ahead and click on Add Button and
can say that, hey, this will have a first name, something like this first name and then you can add
last name.
But I have found that if I use this kind of mind mapping, it actually creates so many of the threads.
So what I do now is I go ahead and delete all of this, and in fact, I just put up a sticky note right
in front of it.
Probably this is sticky note, this color is good.
And I'm going to say, hey, I need your first name.
I will be needing a last name.
I will be needing probably country.
I will be needing email.
Of course I will be needing password from the user as well.
And for my personal I will be using a token.
Now while we are using token because token is a unique information which will be sent to the user and
we'll talk more about how we can send the this token and how it is being generated, all of that.
But remember, this is just a unique information that we can send to the user that if you want to access
any protected route, you have to use this token, you don't have to use your ID and password again
and again, and we can also kind of automate that system.
So this is how my user will look like.
Now, it can be more complex as well, but this is all what we have.
So again, this is a really nice way of handling that notice here.
I haven't mentioned that the first name should be String or the country should be String or something
like that or password should be like a combination.
Now we don't do that.
We usually do that in the modeling.
This is just a basic overview of how it will look like.
Now, again, this is a little bit of a rudimentary way of doing it.
In the professional versions, we actually use all the tools that helps us to build all of that and
have a visual of that.
But this is still a good visual.
Okay, now this is all done and settled up.
It's a good time that we go ahead and replicate this into the code file.
So finally, yes, finally we are going onto creating our application and let's go ahead and use Mongoose
as well as learn how we can design this a schema onto the code files.
Let's go back into the code section.