| The flaw in socket.io had to do with redis-store. When deploying socket.io over multiple Node.js processes / servers, you want to use redis-store, at least, that's what they recommend. When you use redis-store, after running for a while, it puts your CPU usage at 100%, and you have no idea that it was because you used redis-store. Socket.io therefore is only really optimized for running a single process, which of course breaks down as soon as you have any significant I/O throughput or hit a certain # of connections. Same issue happened to me when using the Node zmq library. Inexplicable increase in CPU, which took 3 months to later fix. I could really go on, but these are mission critical libraries that have obscure bugs that are extremely difficult to track down and will bite you in production. Before I'd ever consider using Node.js again, I'd wait for - 1.0, this is taking too long. And even when they release a 1.0, it is more likely to be for marketing purposes than actual product stability. - Library Maturity (maybe another 2-3 years) - Better error handing. Nothing is worse than being left wondering why your server is failing in a production environment without relevant context and information. Another problem with the Node.js community (not all, but a lot) is that you have all these former front-end guys who can build great APIs with pretty web sites that make you believe the library is battle tested and safe to use, when in fact nothing is further from the truth. |