Re: Hosting a Large Number of Node Apps on the IBM i

Aaron

what you are stating doesn't make sense. Javascript is known as a single
threaded
event driven and asynchronously (not to be confused with muli-threaded) OO
language
(Class or Prototype based).

Google's V8 javascript machine that runs in your chrome browser is exactly
the same that
the one that runs in node.js.

Putting a layer benieth it om a server that just executes instructions here
and there would
completely ruin the language and the JVM since you can't be sure that one
instruction in line
100 is processed before line 101 that may rely on result in line 100 is
finished.

On Wed, Oct 14, 2015 at 6:38 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

I'm always open to other points of view.

There seems to be general agreement about external reverse-proxies /
load-balancers being an effective means of "routing" work to multiple
Node.js instances (Jobs), which ensures scalability and fail-over support.
There doesn't seem to be much distinction whether one uses IIS, NGiNX,
Apache, or whatever for external request routing.

It would be nice to see some benchmarks pertaining to Node's internal
load-balancing via the "Cluster" module. I'd be a bit wary of it after just
reading the documentation.

The question that has me the most stumped is the one about "routing"
potentially thousands of URLs to appropriate JavaScript routines, with each
routine pertaining to various "applications" within "modules" within
"major-system-areas" (however you organize you broadly-scoped services)?

Kevin indicated that Node has to be restarted each time a routing
configuration changes in Sails. Inline-coding of routes in Express
obviously suffers from the same problem. I'd be concerned about performance
as the number of URLs increase.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.