Node.js event versus server-side thread programming

Question

We are planning to launch a rather complex web portal that is expected to attract good local traffic, and my boss told me to review / analyze node.js for the service side. I think scalability and multi-core support can be handled using Nginx or Cherokee.

1) Is this node.js ready for serious / large business?

2) Does this server-side event / asynchrony paradigm have the ability to support heavy traffic and work with data? given that "everything" is processed in one thread, and all live connections will be lost if it crashes (although it is easy to restart it).

3) What are the benefits of event-based programming over the stream style? or vice versa. (I know the higher cost associated with thread switching, but the hardware can be compressed using an event model.)

The following are interesting, but controversial (to some extent) work: -

1) http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html

2) http://pdos.csail.mit.edu/~rtm/papers/dabek:event.pdf

Answer 1

• Node.js is developing extremely fast, and most of its functionality is solid and business-ready. However, there are many places where it is missing, such as database drivers, jquery and DOM, multiple HTTP headers, etc. There are many modules that are suitable for every aspect, but for the production environment you need to be careful to choose stable ones.

• In fact, it is much more efficient using one thread, and not a thousand (or even fifty) from the point of view of the operating system, and the tests that I read (sorry, they are not at hand) to find them and link them later) show that it is capable of supporting heavy traffic, but is not sure of access to the file system.

• Event Based Programming:

  • Cleaner code than threaded code (in JavaScript, for example)

  • The JavaScript engine is extremely efficient with event handling and callback handling, as well as easily one of the languages ​​that see the very optimization at runtime.

  • It’s harder to adapt when you think in terms of control flow. With events, you can never be sure of the flow. However, you can also think of it as more dynamic programming. You can consider each event as independent.

  • This makes you more secure when programming for the above reason. In this sense, it is better than linear systems, where sometimes you take sanitized input for granted.

As for the two articles, they are relatively old. The first tests against this, as you can see, have a more recent note about these studies:

http://www.eecs.harvard.edu/~mdw/proj/seda/

He also refers to a second document that you linked about what they did, but refuses to comment on its relevance for comparison between event-based and streaming systems :)

Answer 2

Try to find out the truth.

Answer 3

See What is Node.js? where we pinpoint:

Node in production is definitely possible, but far from the turnkey deployment of what would seem to be documented promise. With Node v0.6.x, the "platform" was integrated into the platform, providing one of the main building blocks, but my "production.js" script still has ~ 150 lines of logic to handle things like creating a log directory, disposing of the dead workers, etc. For "serious" production service, you also need to be prepared to suppress incoming connections and do whatever Apache does for PHP. In fairness, Rails has this exact problem. It is solved using two additional mechanisms: 1) Putting Rails / Node for a dedicated web server (written in C and tested to hell and vice versa), like Nginx (or Apache / Lighttd). The web server can efficiently serve static content, maintain an access log, rewrite URLs, interrupt SSL, apply access rules, and manage multiple sub-services. For requests that fall into the actual Node service, the web server proxies the request. 2) Using a framework such as Unicorn, which will manage work processes, process them periodically, etc. I have not yet found a Node working structure that seems completely baked; it may exist, but I have not found it yet and am still using ~ 150 lines in the "production.js" manual rental.