Node.js, MongoDB, and the “JavaScript Everywhere” method of doing stuff

Be forewarned, this post is INCREDIBLY nerdy, heavy on code, and utterly lacking in pictures of my dog. Sorry.

This week, my homework for myself is to really learn MongoDB. I dabbled with it a few times a while back, but as an old hand with SQL, I’ve been hesitant to delve into new database formats. And the DBA in me has nothing but vitriol for the whole idea. “It’s not even relational!” my internal DBA sneers. “What if you need to query two different records and perform some kind of calculation on them? You’ll have to do that in whatever you’re using to talk to it! Stored procedures are right out! I want my LEFT OUTER JOIN statements! WAAAAAH!”

Then he curls up in a ball and starts sucking his thumb.

Once I give him a pacifier, he calms down enough that I can look at MongoDB more or less objectively. And what I see may make my internal DBA throw a fit, but it makes my internal JavaScript developer do a happy dance. Complete with maracas. (Bet you were wondering where JavaScript would come into this).

JavaScript is the language of the interactive web. Any time you click a button, see an animation, log in, or do pretty much anything interactive, it’s JavaScript doing the work. Wouldn’t it be nice if you could use JavaScript at all stages of web development? Unfortunately, in a traditional LAMP back-end environment (Linux, Apache, MySQL/MariaDB, PHP), there’s no JavaScript to be found. You need to know your way around Apache configuration files, SQL syntax, and PHP.

Let’s look at the trip an array of data might take from a traditional SQL database, through PHP, and finally into the JavaScript running in someone’s browser.

In SQL, you might have a table of personnel records called “people” that looks like this:

name            age             dept
-----------------------------------------------
Jane Doe        32              Human Resources
John Smith      26              Facilities
...(and so on)...

Now, that’s sitting in a database front-end users can’t directly access. (If they can, stop reading and go fix that right now). So you need PHP or something like it to access the data and display it for front-end users. That PHP might look like this:

$SQL = "SELECT * FROM people";
$result = mysql_query($SQL);

$i=0;
while ($row = mysql_fetch_assoc($result)) {
    $people[$i]['name']=$row['name'];
    $people[$i]['age']=$row['age'];
    $people[$i]['dept']=$row['dept'];
    $i++;
}
echo json_encode($people);

That last bit at the end, with the “json_encode”, is how to make PHP spit data out in a format JavaScript can do something with, called JSON. The end result will look like this:

[
    {
        "name": "Jane Doe",
        "age": 32,
        "dept": "Human Resources"
    },
    {
        "name": "John Smith",
        "age": 26,
        "dept": "Facilities"
    }
]

That’s very JavaScript-friendly. If we were to set a variable in JavaScript manually with the same data, it would look almost identical:

var people = [
    {
        "name" : "Jane Doe",
        "age"  : 32,
        "dept" : "Human Resources"
    },
    {
        "name" : "John Smith",
        "age"  : 26,
        "dept" : "Facilities"
    }
];

It’s a method that works, but man… It would be really nice if the data structure, and how I interact with it, stayed the same at every step.

That’s where MongoDB, and other document storage databases like it come into play. See how that looks in JSON and JavaScript? That’s also how it looks in MongoDB’s BSON format. Get Node.js in there (a server-side implementation of JavaScript), and suddenly instead of a LAMP stack, you have a web server stack that’s basically JavaScript at every step of the process. The “people” records will look and behave the same way in MongoDB, a node.js web server, and JavaScript in the browser.

That’s JavaScript at every step.

None of this is to say that my internal DBA is wrong when he freaks out a bit. This is not a solution that is suitable for every circumstance. Relational databases are very, very powerful in their own way, and for a lot of tasks, a document storage database is not going to be the right tool for the job. But when it is, it means you can use the same skill set across the board. There are plenty of complaints to be had regarding MongoDB and node.js, but there are very good reasons they’ve become so popular.