A quick recap of what was discussed in the previous part of this series:
I talked about View Engines and Database. I also shared links to the MDN articles that will help you make decisions when selecting a View Engine or Database. I also mentioned ORMs and ODMs which are one of the two ways we can communicate with the preferred database, the other way is using the database native query language.
Today, I want to talk about Models ==> Controllers ==> Routes and how I created them for the local library project following the Mozilla Development Network Node.js & Express Tutorials.
I already have an account on MongoDB cloud facility, all I needed to do was to create a new database and cluster. The process is well explained in the Mongoose section of the MDN tutorial.
However, here are some tips that would save you some time and headache:
In the "Connect to Cluster" section, you need to add an IP address that will allow you connect to the database from anywhere. The address given in the tutorial, '0.0.0.0/0', will not work as at the time of writing this post, what you want to type in there is '127.0.0.0.1'.
When you copy the connection string according to the last part of the instructions for setting up the MongoDB database, change 'test' in the connection string to 'local_library' as this is what you titled your database and you'd most likely be looking for your data after populating the database in the wrong place if you do not make this change.
After setting up the cluster and database completely, you now want to go back to edit the IP address you entered, the page will be opened up on another tab and as at that time, you'll be able to type in '0.0.0.0/0'.
Mongoose is then installed and the script to connect to the database is seen in this section of the MDN tutorial.
Another serious tip:
Mongoose.connect returns a promise, please remember to handle this by calling the .then and .catch or however you choose to handle the promise. The code linked above did not include this part.
You also want to add another option inside the connect object other than useNewUrlParser, useUnifiedTopology, this should also be given a value of true just like the useNewUrlParser, see the snapshot below.
At this point, we can now talk about Models ==> Routes ==> Controllers.
Models help us define a structure for our data. We can however not create models if we have not designed a relationship between the different parts of our application. For our models, Mongoose provides the 'Schema' interface. This interface helps us define the models we need for Local Library.
When designing models, it makes sense to have separate models for every object - a group of related information, e.g select-list options
The Schema describes the value type expected for a particular item.
examples of the models for Local Library includes:
- book.js Mongoose also provides the 'virtual' interface. A virtual is created in a model and it can be used to get the named URL required to get an instance of a model. We can use this property within the template when we need a link to a particular author, for instance.
Controllers are basically functions that separate out the code to route the request from the code that processes the request. Mindboggling, yes? worry not, I will explain.
Basically, what the controller does is that it provides the data required when the route linked to the model property it is attached to. For instance, under the authors model, we have a property in our controller linked to this model called the author_list, this controller property displays a list of authors. Eventually, the route linked to this author_list calls the controller which in turn calls the model and a call is made to the database which provides the list of authors.
A route is a section of express code that associates an HTTP verb (GET, POST, PUT, DELETE), a URL path/pattern and a function (controller) that is called to handle the path/pattern.
Routes can be considered to be the URL handling code. The Express Router is required and used within the module. The controller files are also required so that the different parts for each model can be routed to if they have some data to be displayed.
Basically, the route calls the controller, the controller calls the model and the model calls the database, once there is a response, the data is sent back all the way to the controller which provides an HTTP response and/or provides the content for the template.
In this article, I talked about setting up the database and clusters needed for the Local Library project, I also talked about Models, Controllers and Routes and how they work together to present data to the View or as an HTTP Response.
In the next write-up, I will be talking about Displaying the Library Data to the view and other related topics.
P.S. Some data was used to populate the DB using a populatedb.js file which contained scripts pushing the data to our MongoDB database. Inside the populatedb.js file, you also want to handle the promise that mongoose.connect method returns as it was not also handled in the script.
Follow my progress on Local Library
See you next time!