There are two Node projects that I've been part of which illustrate some of these problems:
The first one is a hobby project of mine, admittedly a small app with no more than 300 users connected through websockets. Node was fantastic for this use case (and I replicated this model afterwards for a largish gambling site I contracted on): listening for connections, keeping them open, manage their relatively minimal state, and buffer relatively small streams. At no point in the app is there more than one stream per connection in the air. Backend requests are issued quickly and return quickly.
This works so well because the actual backend processing is a separate construct. Even though websocket connections can and do stay open for days, they don't drain a lot of resources (except for a small amount of memory for state and data buffers). No part of the service - except for the dead-simple broker core - will ever be in a contentious state or stranded midway through an action waiting on an unreliable communication partner.
Howeve, this isn't always feasible. My second example is a Node.js project I consulted on for a bigger company. The architecture was quite different: there were the same client-facing persistent connections to manage, but on top of that the backend logic was so immensely stateful and data-laden that a large chunk of it was actually implemented right in node. This meant, because streams and callbacks seem so misleadingly elegant sometimes, that situations occurred where lots of file streams, database connections, and all sorts of backend systems had to be kept in lock-step with the frontend-facing Node.js client connections.
It's no surprise this construct choked, a lot. Some of these are actual hard choices, for example where large and long-running data streams are concerned, but in the end we managed to make the entire thing stable by decoupling client-facing mechanisms from backend resources, and yes: by putting some blunt restrictions in place.
Like with any technology, you need to be aware of the tradeoffs.
The first one is a hobby project of mine, admittedly a small app with no more than 300 users connected through websockets. Node was fantastic for this use case (and I replicated this model afterwards for a largish gambling site I contracted on): listening for connections, keeping them open, manage their relatively minimal state, and buffer relatively small streams. At no point in the app is there more than one stream per connection in the air. Backend requests are issued quickly and return quickly.
This works so well because the actual backend processing is a separate construct. Even though websocket connections can and do stay open for days, they don't drain a lot of resources (except for a small amount of memory for state and data buffers). No part of the service - except for the dead-simple broker core - will ever be in a contentious state or stranded midway through an action waiting on an unreliable communication partner.
Howeve, this isn't always feasible. My second example is a Node.js project I consulted on for a bigger company. The architecture was quite different: there were the same client-facing persistent connections to manage, but on top of that the backend logic was so immensely stateful and data-laden that a large chunk of it was actually implemented right in node. This meant, because streams and callbacks seem so misleadingly elegant sometimes, that situations occurred where lots of file streams, database connections, and all sorts of backend systems had to be kept in lock-step with the frontend-facing Node.js client connections.
It's no surprise this construct choked, a lot. Some of these are actual hard choices, for example where large and long-running data streams are concerned, but in the end we managed to make the entire thing stable by decoupling client-facing mechanisms from backend resources, and yes: by putting some blunt restrictions in place.
Like with any technology, you need to be aware of the tradeoffs.