I ever will come back.
So and this is what we are going to be discussing what exactly is a database and why we need a database
in our web applications.
Why do we need to add it into our API or in general anything.
Right.
And so yes let's get right into it.
So let's just define what exactly is a database.
A database is just a structured set of data held in the computer.
So it's you can think of it as a collection of data that is stored inside the computer.
So why exactly is this useful.
If you think about all the computers that we've been or all the web applications or API that we've been
developing so far we basically have a server over here so I'll draw a server and then inside this server
I have my application running and then the user is basically from his own browsers or lots of allright
browsers and lots of users have browser one browser to all the way to lots of brothers and every one
of them makes an HDTV request a miser right to request a specific page so HTP page.
Right.
But if you think about it this this mechanism over a year is only good for a few for a few cases right.
Well if you think about any of the pages that you interact with usually not only that you just request
to see some information you get it a little.
Let's think about Facebook for example Facebook and Facebook you have to log in into your account and
then you can post stuff.
And if you close Facebook then this stuff is not gone right.
You would expect that your posts would remain there until you delete them right.
Or you hope at least that they would lead them right.
So what exactly.
How can we achieve this with what we know so far.
So what we know so far is just a one way thing.
Right we have a request.
So we have a request and then this request is hey get or post this information to the server and the
server has to do some computation over here and then reply me just the response right.
And that's usually 200 and then maybe it's a J song file with some information for the browser.
As we've discussed before now what about if this user wants to sign up.
Well how do I know that this is the username and the correct user name and password for this user.
Well they use it let's say the user tries to sign up.
So he sends his information username and password over the Internet to me.
And so now I have this username and password right.
And I have to do some computation and tell him OK you're registered now but let's say he closes the
browser and that opens it again.
How do I know that this is exactly the same person right.
If I want to know that well the only way I can know this is if I knew his username and I know his password.
So if I don't know these two things if I don't know his username I don't know his password then I can
verify right because this person might tell me hey I don't know if this username is cold.
For example in his password is 1 2 3.
So hopefully your password is not 1 2 3 but if this is the username and password then this guy might
tell me hey I'm OK.
Right a lot of me instead of this guy.
So the only way we can verify this is if I store the username and password of this user somewhere.
And that's exactly the idea of a database database.
We're to put a database here.
The whole idea of a database is to store these types of information.
So a database you can think of it as a big document.
OK.
And it's full of fros row on row to all the way OK.
Lots of rows and then each of these rows might have each of these customers might have a different idea.
Right.
And then a different username and then a different password.
Right.
Hopefully you don't store the password in plain text editor.
God talk about that in later videos but this is the password or what they commonly call in in development
the hashed password and so on.
Lots of fields for example date of birth maybe and so on.
So you'd have a book or a document that looks like this and then you whenever a new user or whenever
a new user sends you that information from the registration form you would get this information and
then you say OK I have a user name so I'm going to add a new row into my database so you communicate
with the database while you're computing and then you say OK I'm going to put the ID the next ID's for
example 3 and then I'm going to put the user name and his password so I'll just put some stars over
here to denote the password.
And then the date of birth and fill all this information into your database and then once you're happy
with this once this information is.
So once your database tells you OK right once your database tells you everything the story to hear then
you can information and say hey you know what I've registered to you.
So now the next time someone wants to log in if this guy is a sneaky guy and he tries to log in he tells
you Hey I'm a and my password is you know is three to one for example that you and you would he would
send you this information by a post.
And then he would tell the database Hey do you have any user which which is called a and has this password.
So you look here and then you would notice that this is not the password right because the original
password is 1 2 3.
So you add the database with all your ah I don't have this username and password.
So you would reply this user.
I'm sorry I cannot lie you end right.
This is an invalid password.
So in other words a database is just a document to keep track of things.
Once the the the whole request and response is gone right.
Because if you only rely on the response and the your request and the response then you can how long
you lose a lot of information right.
For example Facebook wouldn't be able if you'd get the post and then they don't store it somewhere.
Then there's no way that this brand.
Next time you log in then the Facebook will tell you sorry I did.
I don't have a database.
I didn't store it right.
So so for all that.
Although although AP is that we've been doing we have done only one API right support slash and slash
divide or division and slash multiply and slash subtract right.
And if you notice something about this API is that it doesn't need any information to be short and that
the reason is well we don't have any.
Well we don't we don't need to store anything right because the operations that these API were doing
was basically just add divide multiply and subtract so they don't need any information they don't need
any username password right.
And your user who sends his request we can automatically handle his request right.
But usually that's not the case.
For example if your API is paid then you might want to store here how much how much money this user
has in his credit.
Right.
Let's say you give this user $100 right and he tell him if you want more more to do more API calls then
you need to pay more.
Well this user might might if you if he wants to log in then he has to have his own username and password
right.
To make this call and to subtract a little bit from his money for every call.
So that's the idea of a database really is that we need to store a lot of information or we need to
store information about the customer mainly the customers and all the information about their usage
of the service.
For example some people might even have a difference.
Michael this database one so people might have even a second database so let's call it a database too.
And that inside this database do they would store different things for example customer I.D..
Customer ID and then they would store the type of API calls or API call Vasos little bits smaller spacier
and then you would say for example that user id 3 sent me an API call as Slash had at this date for
example.
And then he called slash multiply right.
So some people might want to know OK what's the most famous API call that that the people are calling
in my API right.
And and for that you have to store it in the database.
Right.
So from now on whenever we think about we want to store something that the user sends us or that we
calculate.
So for example think about maybe a web application that does something that takes so much resources
right.
For example it has to compute the matrix multiplication of two huge matrices.
So instead of having to calculate every time at crunch time we can just store it in a database and then
one once we need it we can access it from the database.
Right.
So the whole idea is to store to be able to store many things like customer information customer usage
of these things or even information that you might need right for for your application to run.
For example you want to keep a counter of how many users are visiting your Web site.
So every time you get a hit then you increase the counter in the database by one.
So for example you got a request plus one and then you get a request again you see how many users you
have and then you add one two plus two now and then you get another eques you see blustery so you add
them plus three and so on.
So anything that you want to store for a long term right.
Not just during the computation.
Right.
So not anywhere or something that you want to store is usually stored in a database.
So there's two types of database.
There is mice or sequel.
No and No.
SIEGEL OK so we're using a no single database for our project it because it's much easier to deal with
Jasons.
So we will be using a no secret code.
Mungo D-B So this one that you might have heard this in the is a famous database now and it uses the
no sequel.
So some examples of sequel databases might be my sequel right.
You might have heard of my sequel This is the oldest type of data.
A lot of the all this but it's very common in the industry to be used.
But also Lovegood maybe starting to use a lot more because it's very fast almost as well not not the
same speed as my sequel but it's very very comparable.
And you know the Mongo baby or no sequel in general has a lot more advantages than sequel which will
discuss it briefly and in a future.
So hopefully this makes sense right where we're going to be you'd be using and no sequel database and
this database is called Mongo NDB.
Right so we're going to be explaining how to use more goodi be and that will use if you want like a
heads up of what we're going to be use and we're going to use this Mongo D-B to make out an application
to improve our application of slash add.
But this time we're only going to allow users to use our API five times.
Right.
And then they have to also supplement apart from x and y they have to supplement also their username
and password.
OK so they have to supply both of these things before they can use the API.
So if the user and if if some user uses the API more than five times then I'm going to reject it.
I'm going to tell him hey you have to pay to go to another time five times.
So hopefully this user infirm user information and password we're going to store in a Magdi database.
And so we can keep track of how many and maybe also how many API calls this user has done.
So for you we can keep track of how many calls that this user has done in the past.
For example one month.
Right.
So yeah.
We'll stop here and in the next video we're going to talk more about this so until the next video at
decoding.