How to set up a database if you’re a front-end developer
Someone recently asked me what’s the easiest way for a front-end developer to save users’ data. So I am going to explain how to do just that.
Setting up the database
The first thing we will need is an actual database. You can head to mlab for a free one. Once you’ve signed up, click create new in the MongoDB Deployments tab. The sandbox database is free of charge, so that’s the one we are going to use.
Once we’ve created the database, we need to create an account so that we can authenticate ourselves. Click on the database name, then users, and add database user. Write down the username and password you chose since we will need them later.
On top of the database’s page, you should see a MongoDB URI. This is the web address of our database. The URI of your database is like the URL for a web page. By convention, the MongoDB URI is as follows:
mongodb://<dbuser>:<dbpassword>@<host>:<port>/<dbname>
Mine, for example, is:
mongodb://admin:superSecretPassword@ds111885.mlab.com:11885/medium
Setting up the server
We are going to use Node in our back end. To avoid having to set it up, you can clone my project on Glitch by clicking here
Have a look at the starting server.js
file I provided:
We start by importing express
— it’s the library we will use to handle requests to our server.
We need use(require(cors))
to allow cross-domain requests. Those are requests from a website hosted on a domain to a server on another domain.app.use(require('body-parser').json())
automatically parses the request to JSON for us.
Then we pass to the get
method the route we want to handle and the callback that will handle it. This means that whenever someone opens the page /
of our website, the request will be handled by that callback. The base domain is implicit, so if your domain is http://shiny-koala.glitch.com, the route /about
will be http://shiny-koala.glitch.com/about.
To be precise, when I say “open the page,” I mean it makes a request using the GET
method to our server. Http methods are just types of requests you can make to a server. We will only use the following:
GET
This method is used to fetch resources from a server. For example, when you open Facebook, it loads the HTML, CSS, and JavaScript needed.POST
This method is used to create resources on a server. For example, when you post something on Facebook, the information that you wrote in that post is sent to Facebook’s servers in aPOST
request.PUT
This method is used to update resources on a server. For example, when you edit a post, your edits are sent to Facebook’s server in aPUT
request.
The app.post
and app.put
work exactly like app.get
, but handle the POST and PUT method instead of GET quite reasonably.
Routing
While you develop the server, you will need to do some tests. To run HTTP requests, you can use the handy site REST test test or the Insomnia application.
To check the URL of your Glitch app click the show button.
So far, we have been using only the route /
. But we want to store different information about different users, so we need a different route for each user.
For example: /ZaninAndrea
and /JohnGreen
Now we have a problem: we can’t possibly code every single route since it’s not a very scalable approach. What we need are route parameters. We will only code one route: /:user
The colon is telling Express to catch any route starting with /
and then only alphanumeric characters.
Some examples:
/ZaninAndrea
will be caught/Johnny45
will be caught/alex/score
will not be caught
We can then retrieve the value of user
in the variable request.params.user
Our server now responds to every query echoing back the username.
Adding data to the database
We know who the user is, and now we want to be able to store some info about him.
To query the database, we will use the mongodb
library. You can install it one of two ways:
npm install mongodb --save
or if you are using Glitch, go to the package.json
file and click the button Add package.
Let’s load the library and store the MongoDB URI in a variable:
The URI is very sensitive information — it’s all that’s needed to access your database. It’s best to put it in a .env
file that will not be visible to others.
Glitch will automatically load the variables from the .env
file to the process.env
variable.
The connection to the database is an asynchronous operation, so we need to wrap all the server setup in a callback like this:
Databases are organized in collections, and collections contain documents (basically JSON files). So let’s connect to the user
collection (it will be created the first time we access it).
First, we are going to handle the POST
route. That is the one we will use when we add data about a user for the first time. Then we will use the PUT
route to update it.
The collection.insertOne
method adds a new document to the collection. In our case, every user will have its own document.
{ ...request.body, user : request.params.user }
leverages the spread operator to merge the data provided through the body of the request and the user provided through the URL.
The result is the document that will be stored in the collection.
The second argument is a callback, and simply notifies the user about the result of the operation.
Getting data from the database
Now that we have some data on the server, we want to be able to read it. We use the GET
method to do this.
This time, the first argument is a filter telling the database to only send us the documents with the correct user property.
The docs are returned to the user in an array, because there could theoretically be more than one document with that user property. It’s up to us to ensure that this doesn’t happen.
Updating data on the database
Last but not least is the PUT
method that we use to update an already existing user.
The first argument is a filter, like the one we used in the GET
method.
The second argument is an update document — you can read more about them here. In our case, we are telling the database to merge the data passed by the user with the already existing data.
Be careful though, because nested parameters will be replaced and not merged.
Farewell
This is far from being a complete guide on databases and back-end programming, but it’s enough to get you started and to power personal projects.
I will probably write about authentication in a future article. Until then, do not use this to store sensitive data.
You can tinker with the complete project here, you will need your own database tough, if you didn’t create one yet, go back to the section Setting up the database.
If you enjoyed this article, please give it some claps so more people see it. Thank you!