Notes of a Pragmatic Geek

by Daniel Khan

Why is Node.js so popular?

Node.js is constantly gaining popularity in the tech community and even big players like LinkedIn, PayPal, Walmart or eBay (to name only a few) already added it to their stack.

This is interesting because often a new kid on the tech block gets much attention from small businesses and startups (look at Rails) but here established brands shift services to a new technology and even replace existing stacks built in Java or Ruby with it.

Somehow there must be something special about- and good reasons to use it.

In this blog post I’ll summarize why it is my platform of choice but also discuss downsides, pitfalls and reasons not to use it.

The benefits

Performance (non blocking I/O)

Node doesn’t need much server resources while providing great performance by using a single thread that executes your code and delegates input/output (I/O) tasks like database or file access to a thread pool.

This is a important asset for modern rich internet applications and high loads and I’ll explain this in more detail in another post soon but please have a look at the Node vs Java benchmarks PayPal did.

No boundaries – one stack to rule them all

With rich JavaScript based web applications on the rise there are often boundaries and interface problems between backend and frontend … and I don’t talk about computers here, I talk about humans.
If the backend coders are working with Ruby and the frontend crew is using Angular there will always be room for misunderstandings and tension because reasoning about code across language boundaries and technology stacks is hard.

So what if the frontend programmer could simply look into the backend code and instantly understand what it is doing?
And what if if you could even re-use code parts in every layer of the application?
This is possible with Node.

Every web developer knows JavaScript and to someone that masters Ruby JavaScript may look a little odd but will be really easy to grasp. It is also not hard to find staff with JavaScript knowledge and the learning curve of Node isn’t steep at all.

Large module ecosystem

Node.js has its own module repository along with a great package manager called npm.

At the time of writing there were over 124.000 packages available. While not all being super stable and well maintained many of them really are.

Great module loader and isolated scope

Nodes module loading mechanism (CommonJS) provides highly isolated scopes by exporting the whole logic of a module into a single variable. This makes code very easy to understand and you have to work hard to not structure your code into small reusable, orthogonal units.

Loading a using module

Loading a using module

 

Self contained projects

This is something I really love about node.

Using php I often had hard times deploying a project to a new server because it comes with a bunch of modules that may or may not be installed on the target host.

With node all modules needed by a project are distributed with it and in most cases you’ll get along with no dependencies to the underlying system. For instance: I develop on OS X and if I want to publish a project I simply copy it to a webserver and start it.

Having solid http support built in most node sites even act as their own webserver which is also a great asset for local development.

Cool and modern

Granted – this is no hard fact. But every good developer loves to improve and extend her knowledge and with Node you will enter a modern application stack that can deal with web sockets, NoSQL databases and spits out complicated datastructures as json to be seamlessly consumed by your shiny new AngularJS app.

So start using Node and all currently hyped technologies are at your fingertips ;)

The downsides

After all this praises let’s talk about things that may be a good reason not to use node.

It doesn’t support static types

Scripting languages use dynamic typing and JavaScript is no exception. This means that it is easy to break code without noticing it and learn about the problem the hard way when in production.

Because no compiler will save you, testing is really crucial here. There are many good testing frameworks out there but you need to be disciplined and we alle know that writing proper tests is the first thing to get dumped when a deadline is near.

Especially for large projects with many developers involved you really have to put much effort into automated testing routines and coding standards and maybe you should think about still using a statically typed language like Java in the backend and let Node act as middleware to your frontend as the graphic below shows.

node middleware

Using Node as middleware

 

 

 

 

 

 

 

 

 

 

You have to care about memory leaks

If you’re doing php development this problem will be new to you, because every time you access a page the whole application is bootstraped. The only state php maintains is your session. After the page is flushed to the browser all resources and data structures you used will be freed (I’m leaving persistent database connections out here for simplicity).

Node is a completely different game.
It does all the bootstrapping when started the first time. Then it will indefinitely process new requests.

If you decide that you want to add an item to a global data structure for every request – maybe you wanted to store all users that connected since the last start – you have crafted a perfect memory leak that won’t be harmful with 10 users per day but will slightly eat up all your memory as soon as your app was featured on TechCrunch.

See here how much effort it took Netflix to isolate a similar problem.

Callback hell and lines of code

Node is about asynchronous programming, so many operations take a callback as parameter that takes a callback as parameter that takes … this is called ‘callback hell’ and looks like this:

https://gist.github.com/danielkhan/0a1ce7ac8129d880807b

Please note: I just wanted to provide a simple example that shows what happens when asynchronous functions are cascaded – in fact in this case we could do the same without callbacks at all, because they are only needed when performing I/O calls like database accesses. I will discuss callbacks in greater detail in one of my next posts.

There are ways to flatten out things like that, but after all your will still need more lines of code to do things like a database query than in a traditional linear control flow

When using callbacks, it is also very easy to introduce hard to find errors like this one:

https://gist.github.com/danielkhan/ac4ec76e8bad0a5f0600

As you see by not returning or using an if/else construct both callbacks will be executed.

Maybe this is obvious to you but it happened to me several times with unpredictable side effects.

Everything is asynchronous – except your code

Your code will be executed synchronously in one single thread – only I/O calls will be handled asynchronously by Node and its event-loop machinery.

So for writing a web based prime number calculator Node is not the tool of choice because while the prime number calculation runs no other requests can be served. To understand that completely we have to discuss Nodes event loop mechanism – this will be the topic of my next post.

What comes next?

Next we will look under Nodes hood to fully understand how code is executed. Expect this post in a few days.

I hope this post was useful to some – feel free to comment or follow me on twitter @dkhan – thank you ;)

Leave a Reply

Your email address will not be published. Required fields are marked *