
We’re excited to hear your project.
Let’s collaborate!
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.
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:
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?
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.
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:
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?
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:
The END!
We’re excited to hear your project.
Let’s collaborate!