
NODE.JS CAKE: Removing Technical Limitations and Developer Complexities of Node.js - shanntfrip
https://robtweed.wordpress.com/2017/04/18/having-your-node-js-cake-and-eating-it-too/
======
al2o3cr
I'm likely missing some nuance here - the QEWD setup described sounds exactly
like the model used to load-balance across multiple single-threaded
application servers in most environments that aren't Node: lightweight,
highly-concurrent front-end server dispatches requests to a pool of single-
threaded application servers. This architecture was well-known back when Node
was created, so I assume they chose a different architecture for a good
reason.

Is there a prefork-friendly GC for Javascript? I know this was a major issue
with the many-single-threaded-app-servers approach in the Ruby ecosystem;
previous versions of the GC algorithm kept GC metadata in the same pages as
data, preventing the CoW memory sharing that prefork servers ideally prefer.

~~~
robtweed
You're right - the QEWD architecture is as you describe, and not that unusual,
though I'm not aware of anyone else having implemented such a design with
Node.js. I'm not sure there was a good reason for Node's not using something
similar, but then again, I'm not really proposing that Node.js should be like
QEWD. The fact is I've been able to implement QEWD's architecture using
standard Node.js capabilities. So it provides a way of working around the
deficiencies of Node that are a direct result of its intentional architecture,
if that's what you want to be able to do - best of both worlds.

Not sure I understand your GC questions, sorry?

