It can sometimes be unclear when a variable set in the client would get to the server and although Now.js has disabled the ability to run client code on the server, it still seems possible a Now.js program could deliberately or inadvertently allow remote code execution via a variable transfer with a function prototype. This seems like a cool idea that could have disastrous security implications.
Then there is the problem with scaling, although this is more an issue with Node.js. The beauty of Node.js is that the system itself is quite simple, which contributes to why so many like it. It is single threaded with epoll/select style network io, exclusively uses network blocking, and runs entirely on event based callbacks. Unfortunately these can all lead to scalability issues including, but not limited to, load balancing and callback spaghetti.
Fortunately, there are a number of techniques and libraries available to help mitigate these issues. A common technique used is to have Nginx Upstream round robin to multiple identical nodes running on different ports. This can make use of all the CPUs on the machine and mitigate the risk of one client hogging all the IO like one grumpy guy trying to return a piece of fruit at the only cash register. Unfortunately, Nginx struggles with the raw TCP of Socket.io, on which Now.js is based, so decided to try to use another TCP load balancer going with the Unix one, Balance, as per the Unix Philosophy: Those who don’t understand UNIX are condemned to reinvent it, poorly.
Unfortunately, it had occasional handshake errors so in the end returned to a single node. In the future will likely switch to HAProxy or Nginx’s TCP plugin to provide fair load balancing via speedy worker threads.