4 ms·

I agree with this - EXCEPT: In a backend where you need a heavy-duty, multithreaded process to handle long-lived computations, node is probably not the way to

I agree with this - EXCEPT: In a backend where you need a heavy-duty, multithreaded process to handle long-lived computations, node is probably not the way to go unless you want to pay for all the extra instances you'd need for the same amount of load. In my experience, for example, a java-based graphQL server (that spawned multiple connections to various services) needed much much less in the way of resources than the node equivalent serving the same amount of traffic - AND the latencies were generally much better with the java server, depending on the size of the JSON payloads that it was handling. All that being said, you can certainly architect your way out of that problem and I imagine a relatively small percentages of web applications even HAVE that problem.

hn_throwaway_99 5y ago
I agree with all of what you said. Note in terms of "architecture your way out of that problem", that's exactly what we did. We have an eventing architecture that uses PubSub to publish to serverless functions that can then do heavier processing asynchronously. And for us, this wasn't a compromise, this architecture has a number of other benefits. But again, I definitely agree with what you've written, right tool for the job.
- pricci 5y ago
  Where can I read more about that architecture you aretalking about?
  - mattacular 5y ago
    Not op but I assume they mean: a main web server is scheduling large jobs in the background by publishing an event to whatever pub/sub system you want to use (there are many!), lambdas can be subscribed to this system so they trigger off these events and publish a corresponding event back when they're done that the web app is subscribed to etc.
  - 8note 5y ago
    For an example, you can look at how node interacts with OpenCV. The JS scripts together the compute heavy CV alogrithms, and you can do similar by hosting your computer heavy things behind a service call, while keeping the orchestration parts in node
- akra 5y ago
  I would argue while it has other benefits it probably isn't as simple. Simplicity is usually the long term better choice. As the business scales since you've probably set a precedent this pattern will be copied all over the place. After enough times trying to understand who owns the data transformations, what lives where, how to support it when one part of the puzzle fails and trying to wire it all and how all these stacks couple together becomes a nightmare. Unfortunately I've experienced some of these issues coming into organizations after the original developers have left once it became too "big" of a place to work for - few people truly understand the architecture and even when they do its flaky and recovery is hard. YMMV depending on the complexity of your business and age. In the end IMO it just seems like a big workaround to keep using Node.

hn_throwaway_99 5y ago

I agree with all of what you said. Note in terms of "architecture your way out of that problem", that's exactly what we did. We have an eventing architecture that uses PubSub to publish to serverless functions that can then do heavier processing asynchronously. And for us, this wasn't a compromise, this architecture has a number of other benefits. But again, I definitely agree with what you've written, right tool for the job.

pricci 5y ago
Where can I read more about that architecture you aretalking about?
- mattacular 5y ago
  Not op but I assume they mean: a main web server is scheduling large jobs in the background by publishing an event to whatever pub/sub system you want to use (there are many!), lambdas can be subscribed to this system so they trigger off these events and publish a corresponding event back when they're done that the web app is subscribed to etc.
- 8note 5y ago
  For an example, you can look at how node interacts with OpenCV. The JS scripts together the compute heavy CV alogrithms, and you can do similar by hosting your computer heavy things behind a service call, while keeping the orchestration parts in node
akra 5y ago
I would argue while it has other benefits it probably isn't as simple. Simplicity is usually the long term better choice. As the business scales since you've probably set a precedent this pattern will be copied all over the place. After enough times trying to understand who owns the data transformations, what lives where, how to support it when one part of the puzzle fails and trying to wire it all and how all these stacks couple together becomes a nightmare. Unfortunately I've experienced some of these issues coming into organizations after the original developers have left once it became too "big" of a place to work for - few people truly understand the architecture and even when they do its flaky and recovery is hard. YMMV depending on the complexity of your business and age. In the end IMO it just seems like a big workaround to keep using Node.