
When should I use Node  for back end? - atulanand94
http://www.atulr.com/blog-atul/web/2016/11/05/nodejs-usage.html
======
santoriv
I imagine I'll get downvoted for participating in the language flame wars
but....

I've been working on a NodeJS backend at my main gig for the last two years.

For two years before that I was working on an backend application written in
C#.

Based on my experience with those two systems, the answer to the question
"When should I use Node for the back end?" should be: Only if your main
language is javascript and you don't have the time and/or inclination to learn
something else.

For me, working with C# was massively more productive. Static typing, robust
async/await, and the fantastic tooling you get with Visual Studio + Resharper
are huge benefits. Dynamic typing, callbacks and/or weird promise logic, and
dodgy open source libraries which may not be very well documented or
maintained are huge downsides for Node JS.

I would never choose to write a new project's backend in Node JS.

YMMV.

~~~
grzm
_I imagine I 'll get downvoted for participating in the language flame wars
but...._

From the guidelines:

 _Please don 't bait other users by inviting them to downvote you or announce
that you expect to get downvoted. _

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

If you think you might get down voted, take extra care to ensure you're
expressing your thoughts clearly and civilly. There are those who will down-
vote regardless, but you can "decrease the attack surface" by writing the best
comment you can.

~~~
santoriv
I apologize. I was unaware of that rule. I won't do it again.

~~~
grzm
No need to apologize. Just wanted to bring it to your attention as you'll
likely get down voted just for mentioning downvoting.

~~~
geon
See!

------
nrjdhsbsid
I beg to differ with node being the "best choice" for IO intensive ops. Java
performance will be better on IO as well, as long as you're using NIO or
something like EPOLL native bindings in Netty, which is asynchronous like node
but also multi threaded.

The point is that node is not that fast. If performance is paramount don't use
it. Node really shines when you need to use client side libraries on the
server. The two best uses I've seen is server side rendering of pages and
html5 canvas for browser based painting apps

~~~
doctorpangloss
In line with my experience as a Java 8 NIO and latest node user, node
basically performs identically to the best Netty implementation in IO-bound
tasks. That parity could be attributed to relentless optimization of a
fundamentally pretty straightforward problem in V8 that finally made it to the
latest node.

My experience matches the TechEmpower benchmarks, which you should check out
here:
[https://www.techempower.com/benchmarks/](https://www.techempower.com/benchmarks/)
. They didn't get much discussion when posted.

~~~
nrjdhsbsid
Fortunes is not IO bound. Plaintext bench definitely is and node is around 8x
slower than the fastest frameworks.

Node is nowhere near raw netty performance in most situations and will never
be. Js is single threaded, dynamically typed, and doesn't have low enough
level access to the OS. Netty has a native network IO interface on linux.

Node is pretty respectable but netty is basically the fastest thing there is
unless you're doing C. It even uses native zero copy buffers with the ByteBuf
implementation, something js doesn't (and cannot) do with its dynamic typing.

The JVM has had a much longer period of relentless optimization and the
language was designed to be well optimized. Js will never escape the
performance penalty of dynamic typing and other decisions without a rewrite

------
0xCMP
While it's true that node can handle CPU intense tasks with WebWorkers or some
other clustering there are also memory concerns. Node _can_ doesn't mean it
_should_ with the exception of keeping your stack simpler (a single language).
But that's a compromise to achieve a different goal.

I personally like Go more these days because it doesn't have these problems,
it's very easy to do concurrency, and it's memory overhead is much lower. This
in contrast to my other favorite option, python, which is a nicer language
imo, but it's concurrency story is worse and memory overhead is about on par
(varying from case to case, but my point being they're both much more than
Go).

------
jayajay
This is why node is powerful when used with AWS Lambda, you can treat CPU
bound tasks as if they were IO. You can also do this by routing the job to a
different processor on the same machine. Node is best when used as a relay or
hub between many services and clients. Let those services do the computing
work, let node manage everything and do the IO work.

Node is kind of like an airport. Airports let you order food, alcohol, and
even other cities. But as soon as you order, all of the work is offloaded to a
third party -- the restaurant, the bar, or the airplane -- allowing the
airport to handle someone else.

------
dvdhnt
The main point of the article is correct; NodeJS is not for CPU-intensive
applications.

Here's a more verbose article on the topic, circa 2013:

[https://www.toptal.com/nodejs/why-the-hell-would-i-use-
node-...](https://www.toptal.com/nodejs/why-the-hell-would-i-use-node-js)

------
embwbam
When your team is composed of node developers.

I would choose it over Python or Ruby, because Typescript and Flow are great
type systems.

Source: lead node dev / CTO since it came out. Currently using Haskell for all
new projects.

~~~
codygman
I would guess that you'd fall in love with Purescript:

[http://www.purescript.org/](http://www.purescript.org/)

~~~
embwbam
I like purescript a lot. But the elm community has won me over. It's well
designed and productive.

------
rajangdavis
Pardon my ignorance, but does Node improve as the V8 engine (or Microsoft's
Chakra engine) improves?

Also, when/if GraalVM becomes public, would Node then be more suitable for CPU
intensive apps?

I love javascript but never quite grok'd it as a server side language. I
wouldn't mind using it, but have never found a good use case and this article
hasn't really convinced me to delve into it.

Edit: I have found that it has been pretty neat for some command line
integrations, but lately, I have been falling back to Ruby.

~~~
nrjdhsbsid
Yeah but I doubt it will ever hit parity with c#/Java/go. The lack of static
typing and other fundamental languages choices will keep it from ever being as
fast as those. V8 and friends were built out of necessity not because js was
ever a good lang to begin with.

I really have no idea why anyone would take a language as terribly designed as
JavaScript and try to put it everywhere. Non existant typing system, crazy
semantics, and lack of true multithreading will always make it second rate to
the others

~~~
rajangdavis
Actually, I could be mistaken, but Node on top of GraalVM _should_ give it
closer parity with Java.

I saw this video
([https://www.youtube.com/watch?v=lYGfD2H99Ls](https://www.youtube.com/watch?v=lYGfD2H99Ls))
earlier this year, would be interested to see when and if this could be
implemented in the mainstream.

~~~
nrjdhsbsid
V8 does almost everything JVM does, the problem is mostly in js dynamic typing
and weak object implementation. There's a lot of runtime checks that just
can't be optimized out. I would expect js to reach maybe a third of JVM
performance but thats probably the limit

------
bikamonki
I use NodeJS like AWS lambda functions but running on my own tiny VPS (Digital
Ocean droplets). Why instead of lambda? B/c I have zero restrictions on NPM
packages and many other things I can use. Now, I do not write full APIs,
instead I use everything a BAAS has to offer (like Firebase) and complement
what it lacks. For example:

\- When a Firebase ref changes I listen to the event in Nodejs and update a
full text search index elsewhere.

\- When a Firebase ref is created I send the appropriate transactional
email/push/sms.

\- Do data validations before pushing to Firebase.

So in general, I do things that cannot/should not be done on the client-side
while still opting for _serverless_ architectures.

PS: Parse.com was great in that it had server-side code that was run on events
like object updated/created. The code was NodeJS. In sum, it had lambda-like
functionality already built-in. But Parse.com closed shop. Not sure if any of
its spin-offs are offering a good service at decent prices.

------
danschumann
I'd still ( and have ) used node for cpu intensive stuff. If you have a long
running computation that can be broken down (mine was 500-2000 steps), you can
break the single process by `setTimeout(...,0)` the next step, so other stuff
can serve pages. Or, you can break it out into a c job.

~~~
RSZC
You might want to check out process.nextTick:
[https://howtonode.org/understanding-process-next-
tick](https://howtonode.org/understanding-process-next-tick)

------
cdegroot
One good spot that comes to mind is when you implement "Backend For Frontend"
style APIs for your clients in a microservices environment. Assuming you have
a single page app in JS, you can have the front-end team own their specific
API implementation and have them work in the language they know best. There's
often also the possibility to reuse some code between the two.

Apart from that, I'm a JS hater, so I would personally always avoid Node - I
neither like the language nor the server-side model, I don't think either one
scales well, and there are better solutions out there for the server side
(besides the JVM and .NET based stuff in the other comments, I like BEAM-based
things like Elixir these days).

------
EGreg
You should use Node.js for back end when you make WEB APPS and want to deliver
real time updates and run background processes. Node.js has a very robust
ecosystem that integrates well with front end Javascript.

------
ilaksh
When the front-end is JavaScript and may share code with the backend or when
you find an applicable package in npm. Or when you know JavaScript better than
other languages.

------
ankurdhama
There are modules that you can use to make node work for CPU intensive tasks.
Search for WebWorkers.

The real idea is don't do CPU intensive tasks in the event loop thread.

~~~
iends
We all have different performance requirements, but in my experience, when you
actually care about the performance of CPU intensive task, child_process.fork
or WebWorkers are still insufficient.

Instead, sometimes you use node native modules, sometimes you separate you
child_process.spawn something written in Go, C++, or Rust(,etc), and sometimes
you set up a separate work "queue" to pass work either on the same machine or
over the network. I've used both kafka, zeromq, or even just files on the s3.
A linux domain socket is nice too.

~~~
ankurdhama
The performance of the CPU bound task and performing any CPU bound task on the
main IO thread are 2 different things. The article was about the problem you
face when you do CPU bound task on the main IO thread.

The WebWorkers and other approaches are about how to avoid using the IO thread
to do CPU tasks. How the performance of those CPU tasks is depends on other
factors. You can use WebAssembly or asm.js code to reach the performance of
natively compiled code.

------
devoply
Go with Go, my son...

------
harshaw
Ok, so for me the problem for Node is:

a) So you reimplemented all of the goodness of twisted in javascript? :) b)
and you have to debug that new pile of code? c) with a language (in it's
original form) that has a bunch of issues, despite being fun to develop in

Maybe Node with an ES6 backend? Maybe that's better. However, from my
perspective, event based development works for some apps but is a total PITA
for traditional workloads (websites).

I would think about Node for a messaging use case, or message processing.

------
RSZC
I don't necessarily buy being blocked by CPU-intensive operations as a
rationale as to why you shouldn't Node, given that it's pretty trivial to
offload these onto a separate process.

[https://github.com/LearnBoost/cluster](https://github.com/LearnBoost/cluster)
\- one I've used

~~~
nrjdhsbsid
It is non trivial to share state between node threads. The state is shuffled
around outside of the VM unlike go, Java, and c#. In those languages, the
overhead of sharing a variable are basically zero.

In node you get sharing at basically the speed of TCP local sockets on the
machine. So maybe 5GBps. With natively threaded languages you get sharing at
the speed of the cpu cache, orders of magnitude faster

If performance is important enough that multithreading comes into play, don't
use node.

~~~
ilaksh
See `webworker-threads`.

~~~
nrjdhsbsid
They don't share variables low level, so the problem remains. In Java and
similar languages the variables are shared at the machine level, including
atomics

------
bitwize
When your boss tells you to.

------
epynonymous
i'm going to get downvoted on this for sure, but basically if you enjoy
writing mindless, infinitely nested callbacks then nodejs is for you.

i liked the package manager npm, but otherwise i prefer golang all the way for
backend code.

~~~
X0nic
I prefer Rails or Elixir, but golang is a solid choice.

~~~
epynonymous
came from ror/sinatra, but really like the deployment ease of golang, just
copy a binary, dont need rvm, ruby interpreter, gems, etc. i think the
performance is much better for golang, but i dont like golang's orms and the
templating languages really suck relative to haml, etc. i mostly use golang
for restful api backends and mobile on the frontend (mobile first), but for
dynamic websites, golang is not that interesting.

------
sauronlord
Never

~~~
nrjdhsbsid
I feel you. My god js is still horrible. Why anyone would willing develop more
than they have to in it is beyond me.

Yeah we have ES(x) coming and typescript and node yay! All of the stuff coming
to js has existed in better form in other mainstream languages for many years.
Even stuff js still doesn't even have on the roadmap like multithreading, true
static typing, and compilation

Are mainstream js developers really that ignorant of what is out there to
suggest running js on the server all the time?

~~~
bobbytherobot
> Are mainstream js developers really that ignorant of what is out there to
> suggest running js on the server all the time?

No. At least not the high caliber ones.

There are those that know only know JavaScript and will try to make everything
fit. Although, you can say that about people who only know Java, or Python,
etc.

