I don't understand the Node.js architecture [closed]

Question

We are considering node.js as a web platform. But I have one crucial question, because I think I don't get the architecture of node.js:

1. It looks like that by default you're forced to use their custom HTTP server, no WSGI or anything?!

2. It looks like that when doing some "real computation" in a response (not only some I/O), all the infrastructure is messed up and ab -n ... -c ... returns enormous times per request compared with e.g. Python -- Pyramid/Flask or whatever?!

3. So, authors of node.js assume that we're doing only I/O or I've missed something very basic?

Answer 1

1. You contradict yourself: "by default" and "forced" are not compatible. You can use whatever HTTP library you want. The core http module may be thought of as a "default," but nothing stops you from using another.

2. JavaScript is a single-threaded language, and Node.js is a JavaScript runtime, not a web server that spawns a thread-per-response like many others. You can still do a thread per response if you want, and there are projects built on top of Node that do this, but you lose most of the benefits of Node. If you are doing computation-heavy stuff in response to a web request (and you have clients who are willing to wait for you to do it), you should spin off a separate thread via one of the many available solutions (web workers, threads-a-go-go, child_process, etc.).

3. The authors of Node.js assume you are writing a web server. Most of the things you do in a web server are, essentially, IO, whether that IO involves a filesystem, a database, or even a message bus used for queuing computationally-intensive tasks on other workhouse processes.

Looking over your question, you seem to have a basic misunderstanding of what Node.js is, if you're trying to integrate it with Python and WSGI. Node.js is for writing web servers, so trying to use it... alongside Python? inside Python? (I'm really not sure what you're trying to accomplish) makes little sense.

If your tasks are not only I/O bound, you should probably not be hosting those tasks on the same box as your web server. Thus, the message bus approach mentioned briefly in 3. But if you are determined to do so, and are sure that those tasks won't hog all the CPU, you should determine how often such tasks are prevalent. If they are on every web request, you should not use Node.js; you are giving up its most basic advantages, leaving only minor ones (like the ecosystem that's grown up around it). If they are rare, then you should spin them off in separate threads via the many methods available in 2.

Relevant: https://gist.github.com/2794861

Answer 2

If you are a Python-based shop, you might also want to consider Twisted which is an event-driven framework written in Python. Twisted is also able to defer long running blocking work to threads.

The most important thing is that you first define what you need and what your problem is. Do not jump on the new fancy thing just because everyone is talking about it. Look at your needs and use something that addresses them.