4 ms·

How to Use Multithreading in Node.js

5 points by stanulilic 4y ago

IceMetalPunk 4y ago
At my job about 8 months ago, since we're rewriting our application to modernize it, I suggested we do our RESTful service rewrite in Node (since we're using a React frontend and having everything in one language would make the transition easier). Leadership immediately rejected the idea with no explanation other than "another team once used Node and had problems with it, so we're not letting anyone use it anymore." Fast-forward 6 months and, by talking to someone other than leadership, I learned what the "problems" were: the team had used Node 5 years ago and couldn't get it to scale because every route blocked all incoming traffic from being processed. And I was just like, ".......you know that Node has threads now, right? And that would solve the problem you just mentioned immediately, right? And if leadership had said this 6 months ago, I could have told them that and we could have avoided all the Java service development we've been struggling with the whole time... right?" Just a "fun" little anecdote about Node multi-threading :D
- salawat 4y ago
  Node's threading model is process based message passing. So when you say node based multithreading what you're actually saying is spinning up a worker process to pass a message to. As far as people using Node wrong goes, there is an absolutely astonishing plurality of ways to shoot yourself in the foot with it, and there is no way whatsoever to reliably import something foreign to your codebase without reading docs/dependency trees/etc... Then you have the nightmare of trying to get people to think in event loops, because node (fundamentally) turns any backend task into a browser execution model pretending to be a backend function. I'm not saying it's the wrong thing for your use case, but I can totally relate to why management/programmers from other paradigms have so much damn trouble wrapping tgeir head around JS.
  - IceMetalPunk 4y ago
    > Node's threading model is process based message passing. So when you say node based multithreading what you're actually saying is spinning up a worker process to pass a message to. Yep, which is a perfect solution to the problem of scalability. > Then you have the nightmare of trying to get people to think in event loops, because node (fundamentally) turns any backend task into a browser execution model pretending to be a backend function. We're a team of professional Javascript developers on the frontend; we know the event loop and task queue semantics very well :) > I'm not saying it's the wrong thing for your use case, but I can totally relate to why management/programmers from other paradigms have so much damn trouble wrapping tgeir head around JS. Fair enough, but like... am I crazy to think that the proper managerial response to "I don't understand this" should be "maybe I should ask the experts I employ" instead of "so no one gets to use it ever"?
    - salawat 4y ago
      >Fair enough, but like... am I crazy to think that the proper managerial response to "I don't understand this" should be "maybe I should ask the experts I employ" instead of "so no one gets to use it ever"? 100% agree for the record. I'm just speaking as the programmer who just spent a couple months banging my head against node till I shook the ignorance out... and I'm regularly told I'm insane by peers in terms of just not quitting/working through things/handling frustration. The pain inherent to reaching professional competency from something like say... Python... is not anything to sneeze at.
lioeters 4y ago
I wonder why they decided to name it "worker_threads" in plural, whereas most module names are usually singular, such as buffer, child_process, cluster. Looking in the Node.js documentation, I see there are a couple other modules in plural: async_hooks, timers, trace_events.

5 points by stanulilic 4y ago

At my job about 8 months ago, since we're rewriting our application to modernize it, I suggested we do our RESTful service rewrite in Node (since we're using a React frontend and having everything in one language would make the transition easier). Leadership immediately rejected the idea with no explanation other than "another team once used Node and had problems with it, so we're not letting anyone use it anymore." Fast-forward 6 months and, by talking to someone other than leadership, I learned what the "problems" were: the team had used Node 5 years ago and couldn't get it to scale because every route blocked all incoming traffic from being processed. And I was just like, ".......you know that Node has threads now, right? And that would solve the problem you just mentioned immediately, right? And if leadership had said this 6 months ago, I could have told them that and we could have avoided all the Java service development we've been struggling with the whole time... right?" Just a "fun" little anecdote about Node multi-threading :D

salawat 4y ago
Node's threading model is process based message passing. So when you say node based multithreading what you're actually saying is spinning up a worker process to pass a message to. As far as people using Node wrong goes, there is an absolutely astonishing plurality of ways to shoot yourself in the foot with it, and there is no way whatsoever to reliably import something foreign to your codebase without reading docs/dependency trees/etc... Then you have the nightmare of trying to get people to think in event loops, because node (fundamentally) turns any backend task into a browser execution model pretending to be a backend function. I'm not saying it's the wrong thing for your use case, but I can totally relate to why management/programmers from other paradigms have so much damn trouble wrapping tgeir head around JS.
- IceMetalPunk 4y ago
  > Node's threading model is process based message passing. So when you say node based multithreading what you're actually saying is spinning up a worker process to pass a message to. Yep, which is a perfect solution to the problem of scalability. > Then you have the nightmare of trying to get people to think in event loops, because node (fundamentally) turns any backend task into a browser execution model pretending to be a backend function. We're a team of professional Javascript developers on the frontend; we know the event loop and task queue semantics very well :) > I'm not saying it's the wrong thing for your use case, but I can totally relate to why management/programmers from other paradigms have so much damn trouble wrapping tgeir head around JS. Fair enough, but like... am I crazy to think that the proper managerial response to "I don't understand this" should be "maybe I should ask the experts I employ" instead of "so no one gets to use it ever"?
  - salawat 4y ago
    >Fair enough, but like... am I crazy to think that the proper managerial response to "I don't understand this" should be "maybe I should ask the experts I employ" instead of "so no one gets to use it ever"? 100% agree for the record. I'm just speaking as the programmer who just spent a couple months banging my head against node till I shook the ignorance out... and I'm regularly told I'm insane by peers in terms of just not quitting/working through things/handling frustration. The pain inherent to reaching professional competency from something like say... Python... is not anything to sneeze at.

lioeters 4y ago

I wonder why they decided to name it "worker_threads" in plural, whereas most module names are usually singular, such as buffer, child_process, cluster. Looking in the Node.js documentation, I see there are a couple other modules in plural: async_hooks, timers, trace_events.