Come Node With Me – Houston, We Have a Problem

• Tweet

• Tweet

Last week we constructed a crude space shuttle in five minutes using Node. This week we’re going to focus on improving it, as what we had last week was a sorry excuse for a shuttle. In fact, we didn’t even have a working web page; we were simply returning a plain-text shuttle. The best we could have done with that approach is ASCII-art, and I just don’t have the patience for that.

“Hey! You! Aren’t you forgetting something?”

Right. It occurred to me last week that I neglected to show you how to install Node and run scripts. Well, I’m still not going to do that. Go check out the official nodejs.org website for that. What I am going to do is cover something else that I neglected to cover, which is how Node is acting as a web server.

As I hope you all understand by now, the code we wrote last week was not running in the browser. It was running on our machines as a system process. As far as our browsers were concerned, it may as well have been running on a server on the other side of the world.

“I think you took a wrong turn at Albequerque.”

When we ran the Node command and passed it the name of our script, our script was interpreted and executed just like a python or ruby script would be. As soon as our script was interpreted, the node process went to sleep.

“Sleeping on the job already? It’s been what, 1, maybe 2 milliseconds since it was executed?”

It’s not sleeping, it’s resting its eyes. It’s waiting patiently for a new connection. When we called the createServer function, what we were actually doing is registering a callback with the operating system. Just like we registered a callback with the createServer function so that we may respond to any HTTP requests, the HTTP object itself registered to listen for any incoming connections. When a new connection is made to the server: Node wakes up, err, opens its eyes, and starts processing its event loop; If the connection closes, Node will close its eyes again and relax. This is one of Node’s advantages, it doesn’t spin in its event loop constantly like a rabid Hamster. No, instead, Node chills out in the corner like an Iguana, expending as little energy as possible.

“So Node just chills when its not busy; doesn’t opening and closing the connection like that get costly?”

Nope, Node is much more clever than that. Node enables keep-alive on all its connections so that the process may sleep while idle, but a heart-beat is sent out every so often to keep the connection alive. Node is also a cool lounge-lizard. Node is laid back, it rolls with the punches and takes life as it comes.

“I am…so confused.”

Just bear with me here. Most web servers spend a lot of time processing your request before sending a response. Let’s pretend that instead of just handing us a shuttle already crafted from our many Legos, our server had to go through the actual process of building the shuttle from scratch. With a traditional web server setup, the entire shuttle would be built piece-by-piece until it was completed, and the finished product would be returned in the response.

“So what’s the problem with that? What am I going to do with a half-built shuttle? I don’t know how to build a shuttle.”

The problem with that is that a shuttle is freaking huge. How fast does the shuttle crawler go, 1mph fully loaded? That’s going to take a long time to deliver to you, maybe even longer than it takes to build it! Node would much rather send you partially assembled pieces every few days so that the shuttle may be fully assembled on-site. So maybe you’ll get some fuselage on Tuesday, the bay doors on Friday, a wing next Monday, and so on. While those pre-assembled pieces are in transit, Node is still busy building more pieces for you. This is far more efficient than leaving completed pieces sitting around the shop while you twiddle your thumbs for 4-6 weeks like you’re waiting for a crackerjack prize.

“Hey! Don’t knock my decoder ring. You know you’re jealous.”

I’m not jealous of your decoder ring, I’ve got a completed shuttle and yours is stuck in transit. Node sent me pieces of my shuttle as they were completed by using something called chunked transfer encoding, a part of the HTTP 1.1 specification. What it essentially means is that Node tells me how much stuff it’s going to send me, how big the next chunk of shuttle is, and once I receive it I’ll know if I’ve received the entire chunk or not. Unlike normal http transfer, where I know only the entire size of the shuttle, I only know the size of the next chunk. Once the shuttle is complete, Node will tell me that I’ve received the last chunk. Stepping away from our metaphor and back into the real world, this means that Node can do all sorts of nifty things like return data from database queries while it’s still retrieving.

“Well, thanks for clearing that up, but what about our shuttle? Have you improved it at all since last week?”

Indeed, I have. However, I’m not giving it to you just yet. I wanted to explain a little more about what was going on under the hood and how Node’s web server worked. Later this week I will reveal our improved shuttle, and also start building the rest of the Johnson Space Center.