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.

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.

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