NodeJS Creeping In
You might have noticed lately, more and more developers are using NodeJS on the server side and the back end.
Lauded as the “silver bullet” developers have been waiting for, to hear NodeJS’s fans, you would think it was slated to take over the development world. Yes, it does well in real-time apps because it doesn’t use web sockets and instead employs push technology.
Which is awesome, because 2-way communication in real time between web apps where clients and servers can freely exchange data is a welcomed change from the typical response paradigm. But, the last thing you want to do is use it for CPU-intensive operations. By doing so, you will void any advantage you had choosing NodeJS at all.
NodeJS can build scalable network apps, fast ones by operating on single-threads using non-blocking I/O calls, and can support concurrent connections by the 10 thousands.
That’s all great, but here is the truth: NodeJS was never intended to solve the problem of computational scaling. However, it was intended to solve I/O scaling and that it does.
NodeJS is not a good idea to use for server side apps if you are using them with a relational database. The database tools it currently offers are not easy to work with and are still in the early stages.
Another place where it’s not the best choice: heavy server-side processing or heavy computation. Incoming requests are going to get blocked, and heavy background processes will need to communicate via a message queue server.
Too Risky To Be A Good Idea