My first introduction to nodejs, backbone, mongodb

July 17, 2015

I finally, after several years, had some time this month to go through a tutorial book I bought called 'Building Node Applications with MongoDB and Backbone'. For those that know the book, yes it is several years old (first edition), and therefore I quickly realised the code was old, and on a fast moving system such as NodeJS was/is the scale of this was large. The most noticeable change was with SocketIO which had a complete overhaul when it hat V1.0+ which resulted in a complete change to how I would use sessions and sockets. This blog is not going to be a tutorial, because for one thing, I may have learnt some bad habits, and secondly, there is a book I used, so really, you should get the book (or, tbh, a newer version of it).

A few of the changes I had to make (and things to be aware of in the future)

SocketIO complete overhaul at V1.0

Things such assio.set('authorization') no longer exist, instead you need to use a genericsio.use(function(socket, next) function. These functions run in order, and there can be multiple of them.

express deprecated req.param(name, default)

This will come up in the notices when you try to run the code tbh, but so you know: 'Use req.params, req.body, or req.query instead'. If you are after using a variable passed in as part of the route URL than use req.params, and if this is a post, then use req.body

backbone/underscore require template options to be passed in seperately

So, instead of something like:

$(this.el).html(_.template(contactTemplate, {model: this.model.toJSON(),addButton: this.addButton,removeButton: this.removeButton}));

You would split the options and pass tothe callback

$(this.el).html(_.template(contactTemplate)({        model: this.model.toJSON(),        addButton: this.addButton,        removeButton: this.removeButton      }));

backbone no longer automatically passes options within this.options

Therefore, when you create your new view in the router.js, just pass in the new variables as you would expect to

profile: function(id) {      var model = new Account({id:id});      this.changeView(new ProfileView({        model: model,        socketEvents: this.socketEvents      }));      model.fetch();    },

then in the actual initialize function, add in options

initialize: function (options) {      this.socketEvents = options.socketEvents;      // Bind a listener to the profile MODEL      this.model.bind('change', this.render, this);    },

Thoughts on the book

I wanted to give my thoughts on the book early in this post (rather than the end, where you would normally expect this to be) largely due to the fact that this was an old book. The fact it was old was very important, I would not recommend this book to someone who wants to go step-by-step through a book with it working first time. That said, I felt this was a really good factor for my learning, as it gave a really good base for the logic of creating this app, but also forcing me to understand what was trying to be achieved, and solve some problems by researching online to see how the code has evolved. I wont pretend this was a quick task though, the book was written when Node was still rather young, therefore documentation from then was a little more limited compared to todays, but there are still a few posts out there with upgrade paths for the more popular elements such as Socket.IO

What I learnt

My first core learning, was on how a NodeJS APP is structured, and how different my mind needs to treat that when trying to resolve a problem. I am so used to handling things such as a PHP application which does bckend logic, with JS doing frontend logic, that having js do them all just seemed to mess my mind and focus up at first. To get around this, I drew myself up a simple diagram showing both how the application is structured, but also how to mentally see it when working on the code.

How does a node app get from request to rendering though? Well, once again, a new diagram was in order I think to show this app process

Another thing was just how sockets were being set up for the application. At first, it seemed a really OTT and convoluted way of doing it, but once I drew out a flow diagram to show the journey, you can kind of see why. One example is that it seems backbone is just receiving an event of one type, and triggering another rather than just handling it all at once. The logic appears to be to have a single file in backbone to hear the node events, then trigger a new event for something like login, this can then be picked up by the other file, and allows for node to create new events on the backend which will automatically exist on the frontend due to the way it is being converted using a 'type' variable to change the handler.

Objects are a big part of how backbone is running, and building them in javascript has not been something I have had to do before. Therefore it was useful to see how define was being used to load in other objects and files, aaswell as how we would create a base object, and extend off of that, rather than extend straight from backbone every time.

I think ultimately, I have a good base now to start working off of, and some working code which I will now put into a private git repo somewhere in case I need it for future reference.

What I might do next (and how this will affect that)

I might actually use this and get something out in the world actually. There are 2 potential apps I would like to build, so will hopefully do at least one of them, as they will be useful to me. I will ensure there is a login/registration mechanism there though, so if others desire it, they can also login to the system created. This piece of training/research though has helped me a lot in structuring and planning how the data will work. Understanding the various models I will need to create, and when having seperate models for things is preferable in bopth the short term planning, and long-term planning.

Closing thoughts

Whilst I have build this tutorial app, it is worth noting there are a lot of things which would prevent it being release ready, but I feel good in the fact I can see these things, and also I can now start to think about how I could address the issues to resolve them if/when I needed to.