In previous installments we looked at getting started with creating an Express.js MVC application, creating controllers and views. And then we looked at middleware and creating a config file to store application constants.
Now we will look at something that truly makes an Express.js application dynamic (and fun): data-access… which essentially boils down to the use of a database to store, retrieve, and manipulate information.
Like many things in technology, people will always argue about what is the “best” way to do something and what the best technologies to use for doing that something are. And the way in which an application should store data is not going to be excluded from this discussion (read: Internet flame-war). It is not really part of our purposes to argue what is “best” or “better” when it comes to data-access, but it is probably worth pointing out that a lot of the Express.js and Node.js communities seem to have embraced NoSQL databases such as MongoDB, and CouchDB. There is even a full “stack” you will hear mentioned known as the MEAN stack (MongoDB, Express, AngularJS, and Node.js) — just like you’d hear of a LAMP stack (Linux, Apache, MySQL, and PHP). The inclusion of MongoDB in this shows its prominence in developer preference in Express and Node applications.
So, it is probably worth knowing a bit about how to use a MongoDB database in a Node.js and Express.js application because you are more than likely to come across it at some point in your life as a developer. So, resultantly, we’ll utilize MongoDB in our application.
Installing MongoDB
Head on over to MongoDBs home page and download MongoDB for your OS. You’ll probably just want to pick the standard install and won’t need any fancy cloud services at this point. Be sure to read through the installation section in the docs section of the site. and do the subsequent tutorials to make sure you can test out that MongoDB was installed correctly. There is a “Getting Started” section that should walk you through this where you can try out creating, reading, inserting and deleting data a sample MongoDB database.
After you have installed MongoDB create a new folder in the root of your application can call it “db”. This is where we are going to store our database and we’re going to point MongoDB to put all the files for this database in here.
To start things up, next go to the directory where you installed Mongo and navigate into the bin directory and open a command window. So on Windows, for example, if you installed in the C:\mongodb directory, you would open a command window or shell in C:\mongodb\bin. You could also get there by opening a command window anywhere and typing
cd "C:\mongodb\bin"
Then you would type the following into the command window where we should specify the path to the “db” folder we just created. So wherever your application lives on your system you’ll want to specify that path by running the following command.
mongod --dbpath "C:\path\to\application\db"
or if you’re using BASH, something like this…
mongod --dbpath /c/path/to/application/db
If all goes well, you should see a message saying that MongoDB is waiting for connections. By default at the time of this writing, the version of MongoDB being used waits for connections on port 28017… so you should see that reflected somewhere in the messaging. Leave this running by leaving this window open (you can minimize if you like).
NOTE: When you first run this command, MongoDB will create all the files it needs in the “db” folder we created, so you should see a number of files pop up in there. Some are quite large.
Now that we have MongoDB installed and we can connect to it, lets write some Node.js code to do some data operations! Woo hoo! Like with so many things we have done before, we will utilise a module to act as a wrapper for our data access with MongoDB. Remember, you could always set things up and write your own code in Node.js for accessing data. Using modules is basically just a way to circumvent all of that grunt work and manual labor involved in those processes. If somebody else has already done the heavy lifting in making a module, might as well make use of it.
Installing Mongoose
I am going to use a popular module for accessing MongoDB on npm called Mongoose.js (which like pretty much all Node.js modules is avialble on npm). There are probably some other modules that you could use, we’re just going to go with this one to start. So as we have done before when we are adding a new module, we need to update our package.json with a new reference to Mongoose. We will also add another module called body-parser which is going to be useful for getting data out of forms so we can save it in our database.
{
"name": "MVC-Express-Application",
"description": "An Express.js application using the MVC design pattern...",
"version": "0.0.1",
"dependencies": {
"express": "4.4.4",
"body-parser": "1.4.3",
"express-handlebars": "1.1.0",
"morgan": "1.1.1",
"errorhandler": "1.1.1",
"mongoose": "3.8.8"
}
}
Then again, we should open a shell in our project root directory and run
$ npm install
which will pull down all the Mongoose and body-parser files.
Read More »
Previously, in an earlier installment we discussed some initial considerations for creating an application in Express.js following the Model View Controller (MVC) design pattern. We’ll pick up where we left off in what follows. The focal point will center around middleware and configuration…
Middleware
One of the things that we are going to want to implement in our application is middleware. There is a pretty good list of Express.js middleware in the Express.js project. Middleware is an important component of Express.js applications. You couple probably think of a middleware function or method as a function that runs on every request/response cycle at whatever point you want to specify. For example, if you wanted to see if the current user who is making the request is authenticated on every single request, you might have this authentication check run in a middleware function before issuing the response. That’s just one example, but there are many other pieces of functionality that you can run within middleware functions.
So let’s add some of the common Express.js middlewares. One useful middleware utility that we can use is a logging component. This will give us information about all of the requests made as our application runs. Express.js uses something called Morgan to accomplish this.
To add middleware, we’re going to want to add it to our package.json file as a dependency. So let’s update our package.json file to look like the following
{
"name": "MVC-Express-Application",
"description": "An Express.js application using the MVC design pattern...",
"version": "0.0.1",
"dependencies": {
"express": "4.4.4",
"express-handlebars": "1.1.0",
"morgan": "1.1.1",
}
}
Don’t forget that we have to install our new module as well. Fortunately, Node.js and npm make this easy. All we have to do is run $ npm install again and all of our packages will be updated…
$ npm install
Now that our dependency is installed, we need to add a reference to it in our main application file…
var logger = require('morgan');
Let’s add the following lines of code to our main app.js file…
/* Morgan - https://github.com/expressjs/morgan
HTTP request logger middleware for node.js */
app.use(logger({ format: 'dev', immediate: true }));
Now if we run our application and look at our CLI window we can see all the requests being output on every request response cycle. And just like that, we have made use of our first middleware.
Read More »
Express.js is probably currently the most popular Node.js framework for building web applications and APIs. It has a good history, a good community around it, lots of modules built for it, and a fairly solid reputation.
In what follows we’re going to walk through how to build an Express.js application using the Model View Controller (MVC) design pattern. It’s likely that we’ll do this tutorial in multiple parts.We’ll start out with a simple application structure and then we’ll move on by adding more complex concepts like authentication, dynamic routing, and reading from and writing to a database.
To start, it’s a good idea to have some background on both Node.js and Express so you know some of the terminology and philosophy behind what is being discussed. If you are not entirely familiar with Express.js there is an introduction to it here. And if you’re not entirely familiar with Node.js there is a primer on Node.js here.
At the time of this writing Express is at version 4.X. If you are reading this at a later point, it’s possible that the latest version differs quite significantly from this. Be sure to check out the Express.js homepage to find information on how to properly set things up using the most current version of Express. However, it may be the case that the steps followed in this tutorial will not be fully compatible with the most recent version of Express.js
package.json
To start we’re going to want to create a package.json file. You can read more about pakcage.json here. package.json will define some metadata type things like the name and version of the application, but most importantly, it will specify what modules you will need to download and run the application. You can read more about modules in Node.js here as well as in any good introduction to Node.js. Express is itself a Node.js module and it makes use of other Node.js modules. Some modules like “http” are core Node.js modules (part of the Node.js core) and some like express.js are third-party. Core Node.js modules will always be available to your application because it is running on Node.js
So our sample package.json file will look like the following…
{
"name": "MVC-Express-Application",
"description": "An Express.js application using the MVC design pattern...",
"version": "0.0.1",
"dependencies": {
"express": "4.4.4",
}
}
One item of note: the name of any given package cannot have any spaces. This is to ensure that installation of packages is easy and consistent across all environments.If people were ever wanting to install our application as a module on npm (if we ever put our application on npm) by running $ npm install MVC-Express-Application it would not work if the package was named MVC Express Application. If we ran $ npm install MVC Express Application, the CLI would get confused.
Now if we run the following from the directory where our package.json file resides
$ npm install
all of the dependencies that we have specified will be downloaded and installed into a “node_modules” directory. The great thing about this is that if we need to update the versions of our modules or add new ones, we can just add or edit this package.json file and run “npm install” again. The npm installer will figure out all of the files needed. We are limited to the modules we are installing right now, but we will be adding a lot more to this later.
Application
Next we’ll want to create an “app.js” file. This file is the kickoff/entry point of our application when it starts up. This is akin to the main() function you’d find in C++ or Java.
The first components we’re going to want to add are here…
var express = require('express');
This loads up the express module. We can now refer to it in our code.
A lot of the modules we’ll be loading up are part of the Express.js project itself. There are many useful items that our application will be utilizing at various times throughout our application. As is described in the Node.js documentation on modules, Node.js modules can be loaded via references to filenames so long as those filenames are not named the same as reserved core Node.js modules, e.g. the “http” module.
Read More »
Templates are a very important part of modern day web applications written in JavaScript. Templating essentially encompasses the visual UI (user interface) components of these applications by rendering different “views” depending on the current state of the application. A “view” can be thought of as a certain type of layout. For example, when you sign in to an application and go to your account settings, you might be looking at a “profile” view. Or, if you were using an e-commerce application and you were browsing the site’s inventory, you might be looking at a “products” view. These views are dynamic in nature because they receive data that gets sent to them and then they render that data out in a manner that is meaningful and useful to the user.
There are many different templating libraries that can be used to render views in a JavaScript web application. No one library is necessarily better than another and it is likely that they all have their various strengths and weaknesses. We have looked at a couple of ways to do templates in Backbone.js applications and we’ll revisit one of the libraries used there: Handlebars.js. Handlebars is one of the templating libraries that I like very much for it’s simplicity and intuitive syntax. The Handlebars.js homepage has some very clear straightforward examples that allow you to jump right in to learning how to use it.
Handlebars template setups will look something like the following…
<!DOCTYPE html>
<html>
<head>
<title>Handlebars</title>
<script src="js/jquery.js" type="text/javascript"></script>
<script src="js/handlebars.js" type="text/javascript"></script>
</head>
<body>
<div class="content"></div>
<script id="artist-list-template" type="text/x-handlebars-template">
<h1>{{ title }}</h1>
<table>
<thead>
<tr>
<th>Name</th>
<th>Hometown</th>
<th>Favorite Color</th>
</tr>
</thead>
<tbody>
{{#each artists}}
<tr>
<td>{{ name }}</td>
<td>{{ hometown }}</td>
<td>{{ favoriteColor }}</td>
</tr>
{{/each}}
</tbody>
</table>
</script>
</script>
<script type="text/javascript">
var data = {
title: 'Artist Table',
artists: [
{ id: 1, name: 'Notorious BIG', birthday: 'May 21, 1972', hometown: 'Brooklyn, NY', favoriteColor: 'green' },
{ id: 2, name: 'Mike Jones', birthday: 'January 6, 1981', hometown: 'Houston, TX', favoriteColor: 'blue' },
{ id: 3, name: 'Taylor Swift', birthday: 'December 13, 1989', hometown: 'Reading, PA', favoriteColor: 'red' }
]
}
var source = jQuery('#artist-list-template').html();
var template = Handlebars.compile(source);
var html = template(data);
jQuery('.content').html(html);
</script>
</body>
</html>
What we are doing here is passing data (in this case the JSON object in our data into) our artist list template (the one with id: #artist-list-template). Note that with our array or artists inside the {{ #each artists }} block (where we are looping over an array of JSON objects) the context has changed so we can directly refer to the artist name, hometown, and favoriteColor properties in for each item
In this example, we are using a static data object that we have created inline but in a real application it’s likely that you’d be getting that data via AJAX requests to APIs somewhere. But whether you get your data from a server or create it locally, the important part is that data can then be passed into the Handlebars template to be displayed by Handlebars. That is where using a templating engine becomes very efficient and very useful. The view/template does not need to worry about handing anything in the data. All of the code to handle getting data and then searching and sorting through it can be handled elsewhere. All your Handlebars template has to worry about is displaying the “final result” that your code generated elsewhere has produced.
There is also support for doing “multi-level” references of you have a JSON object that is x layers deep, you can refer to the properties inside it by normal dot syntax you might be familiar with.
<div class="entry">
<h1>{{title}}</h1>
<h2>By {{author.name}}</h2>
<div class="body">
{{body}}
</div>
</div>
<script type="text/javascript">
var data = {
title: "A Blog Post!",
author: {
id: 42,
name: "Joe Smith"
},
body: "This is the text of the blog post"
};
</script>
And there is even the possibility of doing conditionals via the built-in helper methods. For example, here is an if conditional in a Handlebars template where if a property does not exist or is null in an object that is passed to the view, a different “block” of code will be rendered.
<div class="entry">
{{#if author}}
<h1>{{firstName}} {{lastName}}</h1>
{{else}}
<h1>Unknown Author</h1>
{{/if}}
</div>
And this is just scratching the surface. There are many other features and functionality that Handlebars.js provides. So head on over to the Handlebars.js homepage to start taking a look through the examples there to see what can be accomplished.
As we have seen Handlebars.js is very useful for creating a view layer in single-page JavaScript applications. Ember.js applications Handlebars.js by default, but you could certainly integrate Handlebars into applications built with other libraries. One of these examples is discussed here. But it should also be noted that there is also support for using Handlebars to render HTML on the server in a Node.js application before it is sent to the browser. For example, if you were building an Express.js application, you could use the express-handlebars module to handle the view component of your appplication by creating some dynamically generated HTML to server up to the browser. For more info on Node.js see this entry here, and for more info on building Express.js applications on top of Node.js see this entry here.
Hopefully you have found this discussion of Handlebars.js useful and that you consider using it for your templating needs in your next application. Download the files below to play around with this useful library…
Download Files
When Ghost first made its appearance on the Internet via some initial videos demonstrating its features and capabilities as a new blogging platform, there was a lot of excitement around it. There was an enthusiastically supported Kickstarter campaign that raised a sizable amount of money. Below is the video showcasing Ghost…
Fast forward to 10/14/2013, Ghost released to the general public today. Will this go down as a day that everyone remembers as a monumental day in history, or are we seeing just a frenzy of brief initial energy? Only time will tell, but Ghost seems to have some unique things going for it. For one, it runs on Node.js. This is something that is unique when compared to other popular blogging platforms and content management systems. To learn more about Node.js you can take a look at the Node.js primer elsewhere on this site. While there are probably some other Node-based blogging platforms that have been written by people in the Node.js community, Ghost definitely seems to have the most visibility at present. I like Node.js and I like blogging so it seems like a coming together of some good things.
Secondly, one of the engaging features Ghost possesses is that in creating a post you can use simple markdown (which is also used on other popular sites such as GitHub and Reddit) to easily bridge the gap between entering plain text into an editor and having it be cleanly converted to HTML. And beyond that there is a slick live editing feature where you can see what your post is going to look like in real-time as you edit. You don’t even have to click any preview button to see what you are creating because it is right there in front of you.
And then lastly, Ghost proclaims to be a return to the basics of being “just a blogging platform”. This is where WordPress got its start before it matured into a full-fledged content management system over the years. It will be interesting to see if Ghost sticks to its roots or if people will try to turn it into all things for all purposes.
In 2013, a lot of people use WordPress for their blogs because it is so ubiquitous across the internet. Ghost is likely going to need to have some significant appealing features that really set it apart from something as established as WordPress before it becomes widely adopted. But there are definitely going to be some initial challenges for Ghost to overcome. One is the learning curve of using and developing on a platform such as Node.js which in 2013 is still an emerging technology. Installation and deployment to production will not immediately be available on all web hosts. Additionally, like any piece of software in its infancy, features will be somewhat limited. At its launch Ghost had no native comments system and only supports one user account per blog. So there are definitely a number of elements across the entire stack that need to bake in the oven a bit longer. But these things will come with time and with enthusiastic community involvement things may come quicker than anticipated.
Overall, Ghost looks promising and the future looks bright… so it is definitely something to keep an eye on as it grows and matures. If you want to go check it out, the Ghost homepage can be found here and the Ghost GitHub page is here.
