It's undebatable: Node.js has practically laid the foundation of the real-time web! The real-time, two-way connection web apps have revolutionized the old web response paradigm. The one where it was just the client who could initiate communication, never the server, as well. Even so, there are certain cases when using Node.js is not the best decision you could make.
Specific use cases for which the otherwise flexible and revolutionary web server technology turns out not to be... unsuitable. So:
“When shouldn't I use Node.js?”
You might legitimately ask yourself.
Here are the 3 bad use cases for this JavaScript runtime environment. Scan them through, take note all the factors that I'll be outlining and think them through before rushing to use Node.js to power your next project with.
1. A CPU-Heavy Application: Using Node.js Is Simply a Bad Idea
Face it, deal with it and... adjust your decisions to it:
There are plenty of better solutions (other than Node.js) for powering your CPU-intensive app. It's just not the best technology at hand when it comes to heavy computation.
Now here's why, by using Node.js, you'll only end up “sabotaging” its very advantages, instead of turning it into a true “horsepower” for your app, as you might expect:
- Node.js leverages an event-based, non-blocking I/O model, using a single CPU
- hence, all that intense CPU-processing activity will actually block the incoming requests
- … since the thread will get “held up” with number-crunching
The direct effect of “exploiting” Node.js in the context of heavy server-side computation?
The very benefits of its event-driven, non-clocking I/O model would get practically... nullified in the context of CPU-intensive operations.
Given this, why would you stubbornly stick to Node.js, when there are other technologies more suitable for building your CPU-heavy software with? With better results?
2. A Simple CRUD (or HTML) Application
No need to get your hopes high when using Node.js with a basic CRUD or HTML application:
It might turn out to be just “slightly” more scalable, yet don't expect a traffic flood just because it's Node.js-powered.
In short: use cases like this one, where data's provided, straightforwardly, by the server and where there's no need for a separate API, render Node.js superfluous.
There are other frameworks suited specifically for this type of projects (take Ruby for instance).
Using Node.js in this case would be like driving a Formula 1 car while... stuck in rush hour traffic.
3. A Relational Database-Backed Server-Side App
Why isn't Node.js your best choice for a relational data access type of project?
Because its relational database tools aren't as reliable, robust and easy to work with as other frameworks' toolboxes (take Rails for instance!).
Rails, for example, would “spoil” you with:
- already matured Data Mapper and Active Record data access layer implementations
- out-of-the-box data access setup
- DB schema migrations support tools
- … and the list goes on
In short: if there already are frameworks perfectly “equipped” for this type of project “scenarios”, why would you stick to using Node.js? Since its relational DB toolbox is not (yet) as advanced?
In Other Words...
With these 3 “bad” use cases for Node.js “exposed”, allow me to put together a short “inventory” here, one including all the “gotchas”, aspects to consider before kicking off your Node.js project and limitations to be aware of:
- Node.js hasn't been built with the “solving the compute scaling” issue in mind
- … but it has been created to solve the I/O scaling issue instead
- excepting contexts of CPU-heavy operations, Node.js still is the best technology at hand for powering your real-time, scalable web apps with
- do reconsider your decision of using Node.js if for developing your piece of software you depend on some kind of threading model
- there are also poor quality packages available in npm, free to use in your Node.js application; do keep this in mind as you dig deep into the “load” of Node.js packages
- Node.js will never be “the best choice” for event loop-blocking use cases (take asynchronous parsing XML, for instance)
- … nor for powering apps relying on intense computation
- Node'js “worker” is geared at solving HTTP server calling issues (rather than intense computing issues)
The END!
