3 ms·

What exactly do they mean by "multi-process" in the context of an event loop like Node? I'm also not sure about their claims concerning clustering - Node has no

What exactly do they mean by "multi-process" in the context of an event loop like Node? I'm also not sure about their claims concerning clustering - Node has no SMP capabilities, nor is there any real mechanism for enabling location transparency out of the box. It's also interesting to note the conflict between the microservices and monolithic application camps. Both are just as adamant that theirs is the future and the other is awful. I'm sympathetic to KISS personally, but is there any real consensus forming?

mooreds 12y ago
Wow. Are people defending the monolithic app? Maybe it is where I hang out, but I'm not seeing many. See for example, Martin Fowler: http://martinfowler.com/articles/microservices.html http://martinfowler.com/articles/microservices.html
- TheAceOfHearts 12y ago
  I think it depends on what kind of application you're building, as well as other factors like team size, experience, and time. Microservices aren't magic pixie dust you sprinkle over your applications to suddenly make them simpler and "web-scale". They have a cost in management and maintenance. You can end up taking microservices too far, just as you can end up making the monolith too monolithic. Having your core API all be part of a single application is great. It's my impression that for a lot of applications you can't really achieve good decoupling of resources, so trying to break it up into multiple services ends up bringing you a lot of pain. Maybe this is my lack of experience showing, I'd love to be proven wrong. I'm currently a fan of having a big/medium app that does everything that cannot be decoupled easily, and breaking everything else into services. This is a happy medium, because you don't have to worry about managing tons of services, but you also don't have to worry about having an absurdly complicated monolith.
- deleted 12y ago
  [deleted]
tracker1 12y ago
Nodes I/O base actually uses a thread pool for the C++ bits that run in the background/waiting. For the most part, node/iojs is ideal in scenarios where you are I/O constrained, which is a surprising majority of them. That said, I've run into issues actually using node for stream processing data... taking information from flat files, or sql record queries. In practice very few modules actually implement backpressure properly, and as a result it can/will eat through ram. Exposing GC and running it on every iteration in these instances helps, but once you hit 1-1.7GB of ram use, the process dies in a fiery inferno. That said, you are actually better off running the 32-bit engine in windows environments (not sure about linux, I haven't actually tried to compare). This seems to be more of a puff piece on ARM than Node.js though... I like node a lot, but it does have it's limitations... if you need to process a LOT of data (imports/migrations) and can't chunk or otherwise break out your data, you may well run into issues. In my case, trying to run through 119m records would run out of memory faster than it could manage to push them into a message queue from node, ymmv.
- taurath 12y ago
  This is my experience as well. When there are a lot of small or even medium sized operations or connections being performed (almost all the time), node does extremely well. When dealing with big huge chunks of data at once its not great.

mooreds 12y ago

Wow. Are people defending the monolithic app? Maybe it is where I hang out, but I'm not seeing many. See for example, Martin Fowler: http://martinfowler.com/articles/microservices.html http://martinfowler.com/articles/microservices.html

TheAceOfHearts 12y ago
I think it depends on what kind of application you're building, as well as other factors like team size, experience, and time. Microservices aren't magic pixie dust you sprinkle over your applications to suddenly make them simpler and "web-scale". They have a cost in management and maintenance. You can end up taking microservices too far, just as you can end up making the monolith too monolithic. Having your core API all be part of a single application is great. It's my impression that for a lot of applications you can't really achieve good decoupling of resources, so trying to break it up into multiple services ends up bringing you a lot of pain. Maybe this is my lack of experience showing, I'd love to be proven wrong. I'm currently a fan of having a big/medium app that does everything that cannot be decoupled easily, and breaking everything else into services. This is a happy medium, because you don't have to worry about managing tons of services, but you also don't have to worry about having an absurdly complicated monolith.
deleted 12y ago
[deleted]

tracker1 12y ago

Nodes I/O base actually uses a thread pool for the C++ bits that run in the background/waiting. For the most part, node/iojs is ideal in scenarios where you are I/O constrained, which is a surprising majority of them. That said, I've run into issues actually using node for stream processing data... taking information from flat files, or sql record queries. In practice very few modules actually implement backpressure properly, and as a result it can/will eat through ram. Exposing GC and running it on every iteration in these instances helps, but once you hit 1-1.7GB of ram use, the process dies in a fiery inferno. That said, you are actually better off running the 32-bit engine in windows environments (not sure about linux, I haven't actually tried to compare). This seems to be more of a puff piece on ARM than Node.js though... I like node a lot, but it does have it's limitations... if you need to process a LOT of data (imports/migrations) and can't chunk or otherwise break out your data, you may well run into issues. In my case, trying to run through 119m records would run out of memory faster than it could manage to push them into a message queue from node, ymmv.

taurath 12y ago
This is my experience as well. When there are a lot of small or even medium sized operations or connections being performed (almost all the time), node does extremely well. When dealing with big huge chunks of data at once its not great.