Hacker News Reader

Comment by sillyquiet | Hacker News Reader

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.

View on HN

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.

Where can I read more about that architecture you aretalking about?

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.

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

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.

Reply on news.ycombinator.com