Why do you need a database?

So a database is for persistence, your ability

to store information over the long haul.

So whether or not you quit the server, restart the server,

clients are connecting or disconnecting,

their information is saved.

So a classic example of this is, you made a game

and you need a high score list.

You're going to need somewhere to store that high score list.

Maybe you have different user accounts

with names and passwords.

That's a little bit tricky because we've got

to deal with security there.

But that's something that needs to be stored in a database.

And you can't do this with client-side code alone.

There is something called local storage.

And local storage is a mechanism for your browser

itself to store information locally.

But the issue with that is, if you're saving information here,

this client will never know about it.

If the different clients connecting to your server

need to be able to share information,

that needs to be saved at a database that's

living on the server.

Of course, the truth is, you don't

need to make your own database nor even

keep your database on a server.

You can use something called a Database-as-a-Service.

I've made videos before about Firebase

and how to have the Firebase service store data for you.

There's mLab, which is also a Database-as-a-Service.

It uses the database system MongoDB,

which is a very popular database system.

It's a known as a document database,

meaning the data is stored in basically documents, like JSON

files, in a way.

It's more complex and sophisticated than that,

but that's the core idea.

This relates to what I'm actually

going to do in this video.

But mLab is a service, once again,

that you can send data to, and it will save it for you.

And you could receive data.

You could do all that from the client.

Or you could still use Node, but not actually have the database

on your local server.

So there's so many possibilities there.

And you could actually use MongoDB itself with Node

and have a MongoDB there.

Or you could use something called SQLite.

SQL is beyond the scope of what I want

to do in this video series.

But if you're interested in learning more about SQL,

I might recommend the Socratica YouTube

channel, which has a whole playlist about SQL itself.

What I'm going to use is an open source,

freely available database system called NeDB.

It's very lightweight, very simple.

It's all JavaScript based, and you can run it in Node.

This is not maybe going to be your end solution

for the giant piece of software you're

building for some huge web application.

But for basic database functionality and learning

about how to work with databases,

it's a wonderful system to use.

All of the documentation for NeDB is on GitHub.

I'll be referring to it quite a bit throughout this video.

And there you can also donate to help support

that open source projects development.

Let's take a look at where I left the code off.

Now, I did make some modifications since I last

saw you in the previous video.

I did the exercises I suggested for you.

I did it myself.

And what I have now on the web app page

itself is a Submit button.

So when I press the Submit button,

it sends the data to the server, we can see.

And then I get the success response back.

And I can do that multiple times.

I did it four times.

Now let's look at what the server says.

Every time it gets a request, it's listing, ah,

here's the data.

Here's the data twice.

Here's the data three times.

Here's the data four times.

What it's doing is, it's persistent.

I have a database.

It's an array.

It's a global variable that just starts off empty

when the server begins.

And then every time I receive new data,

I push it into the database.

This is really all that I want to do.

I want something to store every single time I submit a latitude

and longitude.

And I want to be able to look at that thing that I stored.

And an array is a perfectly fine way to start doing that.

It will immediately break down.

As soon as I quit the server, it's gone.

So again, in my previous video, I

suggested maybe trying a text file next or a JSON file.

And I have a code example that does that that I'll link to

in the video's description.

But I'm going to now add the database.

So here on the NeDB GitHub is the documentation that I need.

The first thing that I am going to do

is install the Node package NeDB.

So I'm going to go over here, and I'm going to say,

npm install nedb.

It's telling me to use dash dash save,

but that's old information.

Dash dash save is assumed now.

I don't need to add it in there.

I'm just going to do this.

And we can see that it has now popped up with version 1.8.0

in my dependencies.

The next thing that I want to do is create a database.

So one of the nice things about working with NeDB

is it's a subset of MongoDB's API.

So it's not as big as MongoDB.

It's not as robust or sophisticated.

But if you're learning NeDB, it's

a nice starting point where you might move on and use

MongoDB at some point.

So I'm going to go to Creating and loading a database.

And there's a lot of information in here,

but this is really what I care about.

The first thing that I want to do

is I need to require NeDB, import that Node package, so

to speak.

I'll use the same naming that they use-- const Datastore.

Basically, I'm getting a function that creates

a database, a data store.

nedb-- once I've done that, I can then

make that database itself.

Now, instead of my database being a simple array,

I can just say new Datastore.

And what I'm going to give this data store function

is a path to a file name.

So ultimately, the database is going to sit in a local file

on this laptop, because that's where I'm

running the server right now.

So I'm going to call it it database.db.

That's my very creative name.

Once I've created this data store, it's up to me

to now specify whether or not I want to actually load

whatever is in there.

Now, there isn't anything there right now.

If I look in the Finder, there's no database.db file.

It doesn't exist.

But if I were to say database.loadDatabase, that's

actually going to load the file, load the existing

data from the previous time the server ran into memory.

And if it hasn't ever run, it's going to create that file.

So now I'm going to go over, and I'm going to run the server.

I ran the server.

I go back to the Finder.

And look, there now is a file called database.db.

The next thing I can do is actually go look at that file.

But there's nothing in there, because I haven't ever saved

anything into the database.

And the way that I save something into the database

is with the function insert.

So just to test right now, I can say database.insert.

I'll give it some data, like name, Sheefmahn, status,

rainbow emoji.

And there we go.

Now I'm adding this to the database.

Let's add one more record, and we'll give it a train.

And now let's run the server again.

And now let's look at database.db.

You can see the data that I put in through the Insert

function is literally there in the file as JSON.

There is something new however--

this ID.

A key aspect of working with a database

is having every record, every entry into the database,

be associated with a unique key.

So NeDB is generating this code, this seemingly random sequence

of letters and numbers, to be this particular piece

of data's unique ID.

But ultimately, this is not what I want.

I don't want to just randomly insert stuff into the database.

I want to insert information into the database the moment

that I'm receiving it from the client.

The client is sending data via a post.

The server is receiving it and storing it in the database.

So I can go right here.

And instead of saying database.push data,

I can actually say database.insert.

So just like I pushed into an array, now

I'm inserting it into the NeDB data store.

And it will get saved in that file.

Let's add one more thing, though,

to the data before we put it in the database.

So the latitude and longitude is coming in from the server.

But I also want to add with it into the database a timestamp.

Meaning, what was the time when that latitude and longitude

was recorded?

A way that I could do this in JavaScript is with Date.now.

So Date.now is a function that returns

the number of milliseconds that have elapsed since January 1,

1970.

So I'm going to say, const timestamp equals Date.now.

And then I'm going to say, data.timestamp

equals timestamp.

And then I'm going to insert that into the database.

All right, let's take a look.

I'm going to get rid of the console log.

And let's also add that timestamp here

to what I'm sending back to the client.

OK, so now I am going to rerun the server.

I'm going to go back to the client.

I don't think I changed any code in the client,

but I'm going to refresh anyway.

And I'm going to get the new latitude and longitude, which

is still the same.

And then I'm going to hit Submit.

1, 2, 3, 4.

So good news, we're seeing the timestamp come back.

So something is working and we're

getting a changing timestamp.

If I go to the server, we can see

what's being console logged.

Just, I got a request.

But the real question here is, when I go and look

at the database, will I see all of these entries?

And there they are-- latitude, longitude, timestamp, and ID.

Unfortunately, you'll see I do have this extra stuff still

in the database from when I was debugging.

Just because this is a kind of file format

that I feel pretty comfortable working with,

I could actually just manually delete those and save those.

But I could also investigate the NeDB API

to see if I could clear the database

or just remove certain records.

And certainly, I could delete the file,

and then save a backup of the file.

Everything that's in that file is

what's stored in the database.

So I'm going to just run the server again.

I'm going to submit a few more times.

And we go and look at this, and we can see, there we go,

more entries.

And we're done.

Not done with this project, but done with this step.