A Quick Introduction to How Node.js Works
Join the DZone community and get the full member experience.Join For Free
node.js is popular with big CS nerds. I had a very difficult time understanding exactly 'what it was' when I first heard about it. This is my attempt to explain it for those of us without a neckbeard.
Disclaimer: Some of what I'm saying in this article is not entirely true, I know. I'm over-simplifying how computers work to illustrate how node.js works, not explain how CPU schedulers work. That'd just be a snooze-fest anyways.
Why I'm trying out node.js
node.js is something that I've been very excited about. I've watched/read a lot of what Ryan Dahl and the rest of the community has said about node.js. It's my latest hammer.
node.js is an excellent tool if you want some kind of live interaction on a website. It is capable of very quickly delivering data to/from a web browser.
What could you do with that? Well, as an example, say you were building a CRM. You could have a feature where viewing a customer's profile could be updated live. So if a sales guy is on a call taking comments, another employee could be seeing the updates instantly. (No reloading of the page.)
Yes, this has been done before with ajax and things, but node.js does it much, much faster and better. Even the fastest Rails requests will be 10x what node.js can do.
My job is to use my knowledge of technical resources to solve problems. Node.js allows us to do neat things on web sites that so far really haven't been leveraged by anyone. It's very young and has tremendous potential.
I've also been working on a little toy with node.js. More on that in a later post.
node.js should be used if you want a specific piece of your web architecture to be live and/or super fast
It works well for that, but it doesn't have the same niceties of other web frameworks like rails, django, .net and everything else. It's not that it couldn't, just that it isn't the intent.
If you were building Facebook, for example, node.js would be good for updating the newsfeed when new status updates come in, but not great at much else.
Now, to explain HOW it works
So traditionally, there has always been a big problem with computers where the CPU can only do one thing at a time. It was solved long ago with multi-threading, allowing us to have multiple 'threads' on a single CPU.
So, to simplify, if you have 10 threads going on, a CPU scheduler will split up the CPU's time evenly between all of them so they get equal time slices. So maybe in 1 second, each of the 10 threads would get 100ms.
It switches between them all the time, and while it's pretty fast, the switching has a ton of overhead. I won't get into how, but let's say in my CS class when I learned this I was actually amazed that computers are even as close to as fast as they are.
Avoiding that overhead would be nice.
node.js is evented programming
Why? Let me illustrate,
So, if you think of a blog cms engine, for example. A traditional web server looks like this:
- Take in a request for the blog index
- Call out to the db to get the blog articles
- Build the html containing the blog articles
- Send the response out
Node.js doesn't work any different here. It's under the hood where it's different.
Now, on the second step, (calling out to the db to get the blog articles), let's say that takes 100ms. Almost the entire time the thread is waiting for the db to come back with its response. We call this IO heavy.
However on the third, where the server is building HTML from the database's response, it's crunching that database's response and building HTML. It's quicker, around 10ms, but it's CPU intensive. It's not waiting on anyone, just crunching away. We call this CPU heavy.
Now earlier I mentioned the bit about splitting the CPU's time up between threads. If we have 1 thread where the CPU is crunching the HTML (CPU), and another where it's waiting on the DB (IO), the CPU could literally (and does) waste an entire time-slice switching into the IO thread.
node.js solves this problem by running in a single, event-driven thread
It takes control of deciding what work needs to be done, rather than having a scheduler try to figure it out.
Rather than have a new thread get created on each request, there is one thread for every single request. When a new one comes in, it fires an event that runs some code. VERY much like how jQuery works. When you make a call to a database, for example, rather than block until it's returned, you just run a callback function after the call is complete.
Heavy IO applications benefit well from this, whereas CPU intensive applications will not.
However, most web development is IO intensive, so that's generally an OK tradeoff.
Opinions expressed by DZone contributors are their own.