NodeJS

Welcome to Node.js: Part 2 – Node.js and MongoDB

June 30, 2014

Life is like a MEAN stack… of pancakes.

That really makes no sense at all, but I have successfully made myself hungry for pancakes. In the meantime (no pun intended), I should try to get a firmer grasp of our new friend, the MEAN stack. I know we already covered downloading and installing Node, but I kept finding myself wrestling with the terminology as I tried to proceed with something more useful than Hello World. I’m taking a half step backward into necessary concepts so that we (I) can wrap our (my) head(s) around all of this.

Remember, MEAN stands for MongoDB, Express, AngularJS, and Node.js. We covered the basic definitions of each when introducing the topic, but I (at the least) need to dive into this a little more. We don’t really need to tackle the acronym in order, so we’ll start with the most obvious component: Node.js.

We’ve established that Node.js is, in my humble and incomplete understanding, an assortment of stuff and things that allow the use of Javascript in developing server-side applications. Honestly, the Node.js homepage isn’t really all that helpful in figuring out what exactly it does. This is the introductory headline on the site:

Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

As I read through this and their “About” page I had to read the links of their explanations and examples. Then I had to follow multiple subsequent links or search several terms to understand the supplementary information itself. As with anything tech, there are a million rabbit holes to fall into. I think I may have even blacked out for some time due to acronym overexposure.

A “mind map” of an unrelated topic that nonetheless adequately represents the overwhelming task of learning anything on the Internet.

If you’re reading this blog, odds are high that, for now, we just want enough working knowledge to paint a simple, understandable map in our minds of what happens between client and server now, and how Node.js changes this. After finagling Dr. Google I finally found an explanation that I could understand. And it even has pictures. Mr. Capan, the author of the explanation, helped clear up a few misunderstandings on my part. He says:

Node.js is not a silver-bullet new platform that will dominate the web development world. Instead, it’s a platform that fills a particular need. And understanding this is absolutely essential.

I would strongly encourage anyone starting out at the know-nothing level (like me) to read his entire introduction. Here, I’ll just tackle the crux of understanding the mysterious “single-threaded, event-driven, non-blocking I/O model” Node.js is so proud of.

Normal Internet operations require the server to spawn a new thread every time a client connects to it, and every thread requires a set amount of memory. If ten million customers connect to SuperDeluxLifeInsurance&CottonCandyShop.com at the same time, our poor little fledgling SDLICCS website will probably crash if they aren’t prepared with huge servers. Also, traditional Net requires that all “conversations” between client and server be initiated by the client, making the client largely responsible for managing the flow of information.

Node.js allows the server to handle all connections with only one, dynamic thread. And each connection is a two-way conversation, meaning the server can now talk back to a participating user without having to be prompted first. Any time either party initiates or completes some part of the whole process (i.e. an event), that participant can send or receive the new information without having to wait (much) on the other. I believe this is the heart of the single-threaded, event-driven, non-blocking I/O model.

One other thing: in my mind I had been separating the “non-blocking I/O” idea into “non-blocking” and “I/O” as if they it were two separate ideas. I’m not sure why. So Mr. Capan helped set me straight here, as well. As he explains in a little more detail in his post, Node.js excels at performing I/O operations (which are a notoriously slow chunk of standard Net interactions) without blocking. However, Node can still run into blocking should any CPU-heavy functions be called. These are functions/processes that require a lot of calculations or data manipulations, as opposed to I/O operations which is the sending or receiving of the results of such processes. So Node can be blocked; just not by I/O actions.

Next, let’s look again at MongoDB, because I have something resembling a clue regarding what it is and what it does. If you don’t already know, most traditional databases (DBs) are relational databases, and they’re usually maintained and accessed by a Relational Database Management System, the most common known as MySQL. These traditional DBs are arranged, for most intents and purposes, just like an Excel project: columns and rows make a spreadsheet, a whole lot of spreadsheets make up a book/project. MySQL is the system by which the information in any given cell or cells (often spreading over many rows, columns, sheets, etc.) is created, read, updated, or removed (which, by the way, is yet another acronym: CRUD).

A different kind of database is not arranged like spreadsheets and does not use the row-column relationship. These kinds of databases are not built or queried with SQL, and therefore are known as NoSQL DBs, and MongoDB is probably the most prevalent among them. Mongo arranges all its data in JSON chunks. JSON (JavaScript Object Notation) is extremely easy for us humans to read and also easy for computers to create and use. Also, if the name weren’t a clue, it’s JavaScript native. I don’t understand everything in their manual, but MongoDB has relatively friendly documentation.

MongoDB stores data as document objects written in JSON: you can kind of think of it as one page of paper with the desired info and some necessary contextual stuff it will need to retrieve and update it later. It uses a bunch of clever mechanisms to associate one page with the next if required, and to collect a whole bunch of relevant pages. This is all done to make up for some processing weaknesses relational databases can run into, but, as I understand, MongoDB runs into its own kind of problems in other scenarios. With MongoDB, it depends on the type of data you’re storing and how you’ll be using it.

In choosing Node.js and MongoDB, it comes down to the type of service you need. If your program/app/service is sending and receiving a lot of data very quickly, and it doesn’t require heavy computation, Node.js is probably the right choice. If Node.js is the right choice, then MongoDB is very likely a good fit for your database needs. It is a part of the quasi-official acronym for a reason.