Any anti-patterns of nodejs?

Question

What are the anti-patterns of node.js, what should you avoid when developing with node.js?

Dangers like GC, closure, error handling, OO and so on.

Answer 1

Anti patterns:

Synchronous execution:

We avoid all synchronous execution, this is also known as blocking IO. node.js builds on top of non-blocking IO and any single blocking call will introduce an immediate bottleneck.

• fs.renameSync
• fs.truncateSync
• fs.statSync
• path.existsSync
• ...

Are all blocking IO calls and these must be avoided.

They do exist for a reason though. They may and may only be used during the set up phase of your server. It is very useful to use synchronous calls during the set up phase so you can have control over the order of execution and you don't need to think very hard about what callbacks have or have not executed yet by the time you handle your first incoming request.

Underestimating V8:

V8 is the underlying JavaScript interpreter that node.js builds on. (Yes spidernode is in the works!) V8 is fast, it's GC is very good, it knows exactly what's it doing. There is no need to micro optimise or under estimate V8.

Memory Leaks:

If you come from a strong browser based JavaScript background then you don't care that much about memory leaks because the lifetime of a single page ranges from seconds to a few hours. Where as the lifetime of a single node.js server ranges from days to months.

Memory leaks is just not something you think about when you come from a non server-side JS background. It's very important to get a strong understanding of memory leaks.

Some resources:

• How to prevent memory leaks in node.js?
• Debugging memory leaks with Node.js server

Currently I myself don't know how to pre-emptively defend againts them.

JavaScript

All the anti-patterns of JavaScript apply. The main damaging ones in my opinion are treating JavaScript like C (writing only procedural code) or like C#/Java (faking classical inheritance).

JavaScript should be treated as a prototypical OOP langauge or as a functional language. I personally recommend you use the new ES5 features and also use underscore as an utility belt. If you use those two to their full advantage you'll automatically start writing your code in a functional style that is suited to JavaScript.

I personally don't have any good recommendation on how to write proper prototypical OOP code because I never got the hang of it.

Modular code:

node.js has the great require statement, this means you can modularize all your code.

There is no need for global state in node.js. Actually you need to specifically go global.foo = ... to hoist into global state and this is always an anti-pattern.

Generally code should be weakly coupled, EventEmitter's allow for great decoupling of your modules and for writing an easy to implement / replace API.

Code Complete:

Anything in the Code Complete 2 book applies and I won't repeat it.