If you were to do this on Nginx you'd have to write the module in C.
You can't do it on Apache because of Apache's multi-process/thread model.
Node.js may do for server applications what Perl did for the Web in the 90's.
> If you were to do this on nginx you'd have to write the
> module in C.
> The fact that you can write a web server in a few lines of easy to
> concurrent connections without breaking a sweat is a
If your DB is dog slow, you can still handle wildly high concurrency with node. It's just that the user will feel the slowness, and your DB will struggle. But at least your server won't be unable to serve requests while it's waiting for IO.
Of course it's still on the developer to architect their system for success. Node just takes one unnecessary bottleneck out of the equation.
I think it's a big mistake to judge based on "number of lines taken to write 'hello world'". It's what happens when you have 20k LOC to maintain and a heap of complexity that matters.
I'm curious how suitable node's callback-centric model is for larger codebases - it's workable for smaller stuff, but can turn into spaghetti code quickly, like CPS code or giving someone elaborate instructions in passive voice. (Of course, relatively autonomous chunks of the system can be moved into their own processes.)
Off and on, I've been working on a similar event loop/async server framework in Lua, and I think Lua's coroutines make the resulting code easier to manage. (No time frame on that yet, btw.)