Building Node Applications with MongoDB and Backbone

Chapter 1. Introduction and Overview

The Web, already one of the fastest developing areas in technology, is accelerating. This is both good news and bad news for those of us planning to draw income from writing software. Today, good developers have the rare opportunity to do what they love, grow their horizons, and continually evolve and derive even greater satisfaction from their work, as long as they’re willing to put in the hard work necessary to understand a huge back catalog of rapidly-expanding knowledge.

Terrific careers come at a price. As a software developer, you must continually search for the next great tool that will help you achieve more, better, faster. What you work with 10 years from now is going to be a major departure from what you are working with today—in essence, you will be retraining yourself multiple times to keep sharp.

In his 2008 book Outliers (Back Bay Books), Malcolm Gladwell presents evidence that it takes 10,000 hours of effort to achieve mastery at a professional level. Even prodigies need to put in their time to achieve success; the difference between an average performer and a superb performer comes down to the amount of practice put in by the individual. Picking up a book like this puts you into the latter category; right now you are putting in the extra time to gain more exposure to the leading edge of this craft. The future is arriving, and you will be among the first positioned to take advantage of it.

Node.js has introduced an army of programmers to event-oriented programming. Regardless of what your technology background is, if you come to Node with an open mind and drop any preconceived notions you might have about JavaScript, you will come away with a greater appreciation of how powerful single-threaded programming can be in a world that has gone crazy for multi-threaded applications. What’s more, you will have a greater appreciation of event handling that will help you when you do need to tackle multi-threaded problems in other programming languages.

JavaScript is a unique and sometimes misunderstood programming language that has finally taken its deserved place in the development toolbox. As the toolsets for developing JavaScript applications continue to improve and mature, you can look forward to seeing this language’s importance continue to grow in organizations worldwide.

Building a Social Network

The project in this book examines how you would go about constructing a social network in a similar vein to LinkedIn, MySpace, or Facebook, with a real-time networking twist. Using Node.js, Backbone.js, and MongoDB you will learn how to create a highly responsive application that can be adapted to scale to millions of users.

By way of example many of the components described throughout the text will take some shortcuts to use a built-in method provided by Node or MongoDB in order to demonstrate certain functionality that wouldn’t be practical in “real” large deployments. When one of those shortcuts is presented, I will point it out with a special note and discuss how to begin moving to a more scalable or modifiable construct. The challenge throughout will be trying to balance the need for clarity with the task of building a real and useful application.

What is a social network? “Social network” is a simple phrase that seems to communicate a lot of meaning—and in behavioral science, it does—but let’s look more carefully at the individual words and apply them to the Internet. A “network” is an interconnected group of systems, which could be anything from a series of roads crisscrossing the country to a row of computers in a school lab to a Rolodex filled with professional contacts. The word “social” refers to the interaction of organisms—such as animals or people—and to their existence as an entire group. So a social network in this context means an interconnected, interactive group of people.

The human component is important above all else. When building any kind of software you are remiss to develop toward a particular goal or functionality without first (and constantly) thinking about the person who is expected to use your finished code at the end of the day, whether it is a customer, a professor, or even yourself. Unless you can visualize the end purpose for your work, resist the urge to continue down the programming road for technology’s sake.

When we speak of building a social network, of course it’s impossible to build a social network as defined here. What you will be creating is the forum, the raw pathways, upon which a social network can take root and grow. Every feature of the system is intended to deliver upon that goal by getting out of the users’ way and by providing just enough of a feature set to promote, encourage, and facilitate communication without any extra frills. It’s a difficult line to walk, but one that ultimately separates a mediocre product from a great one.

Model-View-Controller (MVC)

This book makes frequent reference to, and use of, the Model-View-Controller (MVC) design pattern for both server-side and frontend programming. While MVC was arguably popularized on the web by the growth of Ruby on Rails, it was first developed for the Smalltalk platform in the 1970s.

MVC as it is practiced today promotes decoupling your system into three components:

Model

A structure containing the data that is being read or acted upon

View

An interface through which the user interacts with the model

Controller

Delegates user actions from the view to the underlying model

Models and controllers are typically paired; in this book, the controller’s job will be to act as a contract for what a user is able to do to a model, and to pass information back and forth. While it is possible to have a controller perform actions on more than one model, doing so should be considered poor form: one model, one controller.

Views are a different story; just as in real life, in software there is often multiple ways to perceive the same information. For example, a textual transcription of an audio recording contains the same information as the original, but presents its contents in a way that is more accessible to some users or convenient for others. The Internet is full of great examples of this: many web services display data in both JSON and XML format, two different formats that provide the same information in different ways.

Pure JavaScript

Using Node, Backbone, and MongoDB will allow you to focus on your application logic in a single programming language, ultimately reducing the number of connections between each part of your system. As you will see, this is a compelling way to program because the boundaries between client-facing UI, backend server logic, and database persistence will blur into almost a living system. The picture becomes clearer as real-time networking is gradually added; your data will dance across the application and even across multiple users almost as if everything were happening in concert in a single process.

There are pitfalls to watch out for. Although the connectors are strong and speak the same dialect, under the covers your program code is still going across a wire between web browsers, servers, and databases. Some of the JavaScript paradigms change slightly depending on whether their primary goal is to serve UI (as in the case of Backbone in the web browser), authentication (as in the case of Node on the web server), or persistence (as in the case MongoDB). You need to be ever vigilant about where your data is going, whether or not you are blocking any of your own processes, and how to listen for and react to incoming and outgoing events. It can be a challenge, but as with any other system with lots of moving parts, there are a ton of interesting lessons to glean from the experimentation.