Re: Apache vs Express for Node

Do I need to understand something so complex in order to make my JS

application perform it's best?

Javascript before ES2015 was much more complicated. There are new features
that either exist or are coming that make Javascript work in a more
"visibly procedural" fashion. Here's an example of the "await" keyword:

var customer = await getCustomer();
var invoices = await getInvoices(customer.id);
var tickets = await getTickets(customer.id);

The above code looks very normal. To accomplish this in traditional async
fashion would be more busy and harder to understand.


Aaron Bartell
litmis.com - Services for open source on IBM i


On Wed, Sep 14, 2016 at 3:56 PM, Bradley Stone <bvstone@xxxxxxxxx> wrote:

I saw this video a while back too and it is pretty cool.

Here's my caveat...

Do I need to understand something so complex in order to make my JS
application perform it's best?

And if so, is it worth it in the end?

I don't think you'll get your average RPG programmer to even WANT to know
about how JavaScript works under the covers.

Most RPG programmers I have worked with over the years (not counting most
of those here or other places online that contribute/discuss/bicker) would
look at that video and run from JS as fast as they could. :)
Brad
www.bvstools.com

On Wed, Sep 14, 2016 at 3:40 PM, Pete Helgren <pete@xxxxxxxxxx> wrote:

Nice Aaron. All good stuff. It would make a great presentation at

Common

walking through the synchronous and asynchronous components and how they
interact. Until I viewed this video I didn't have much of a grasp on

what

was going on as JavaScript scripts executed. Phillip did a really nice

job

(understandable, too)

Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java
LinkedIn - www.linkedin.com/in/petehelgren
Twitter - Sys_i_Geek IBM_i_Geek


On 9/14/2016 8:00 AM, Aaron Bartell wrote:

Although Node's HTTP process is single threaded, it can be shared by

multiple forked "child" processes as reference by Aaron Bartell. Child
processes are relatively resource intensive in that they run a subset of
AIX (PASE) along with Node's JavaScript runtime.

When I was learning Node the topic of "Node is single threaded" came up

a

lot, and then there were people that said it wasn't single threaded and
that confused me. So I dug deep and here's what I found...

This guy put together an ~excellent~ visualization of how Javascript

works

on the client (and the same storyline holds true for the server).

Highly

recommend watching this before reading my next statements:
http://latentflip.com/loupe

It's true that Node.js is single threaded. And it's also true that you
can
have multiple threads in a single Node.js process (aka IBM i job).

Here's

the kicker... new threads are used when I/O is done (DB, file system,
networking) because that would block (synchronous) the single threaded
Javascript event loop. Only one line of Javascript is being invoked on
the
call stack at a given time in one thread. There could be other threads

in

the same process that have their own event loop, and thus there would be
true parallel execution.

Javascript has additional complexities when used on the server-side
because
the programmer has to be significantly more mindful of writing async

code.

On the client-side it isn't as big of an issue because you have a single
user and they may not notice synchronously written code (that would

block

their interaction with the page) because it happens so fast.

Before last month the IBM i DB adapter for Node.js was synchronous which
would be similar to having a single RPG-CGI job to facilitate all

inbound

requests. In short, everybody waits in line for the request in front of
them to run its course. This then necessitates the multiple process

(aka

IBM i job, aka Node.js clusters) approach.

Side note: Upgraded a customer from Node.js v0.12.9 to v4.4.6 on IBM i

and

gained a roughly 2.5 times throughput (tested with JMeter). I only have
assumptions of why we're getting better throughput (i.e. async db

adapter,

probably refined V8 Javascript runtime).


Aaron Bartell
litmis.com - Services for open source on IBM i


On Wed, Sep 14, 2016 at 12:05 AM, Nathan Andelin <nandelin@xxxxxxxxx>
wrote:

So I can use Apache or Express for Node. Can anyone enlighten me as to

the practical differences?

I'm not aware of practical differences in regards to communications

(socket
services) and the HTTP protocol given a relatively small I/O workloads.

For those who may be looking to serve thousands of concurrent
connections,
the Apache based server scales in and of itself; just configure the
number
of threads you want it to support. One of our clients runs 3,500+

threads

in a single instance (1 process). The Node HTTP server is a
single-threaded
process. You can scale by running multiple Node instances and
distributing
workloads between them via a load balancer.

Although Node's HTTP process is single threaded, it can be shared by
multiple forked "child" processes as reference by Aaron Bartell. Child
processes are relatively resource intensive in that they run a subset

of

AIX (PASE) along with Node's JavaScript runtime. Node is an
application-server environment (JavaScript), whereas the Apache server

is

generally used merely for communications, or reverse proxy, or
encryption,
or compression.

More meaningful differences probably pertain to one's interest in using
JavaScript to process web-service requests and generate responses vs.
perhaps one's interest in using ILE languages to do the same.

Another relevant distinction, at least to me, is how web-service

requests

are dispatched and routed. Under the Apache CGI design, requests may be
routed to persistent stateful jobs, or routed indiscriminately to a

pool

of
stateless jobs, based simply on which is available at any given moment.
Under Node, this is where a product like Express comes into play. I

don't

have a high opinion of either the routing in Express, nor in Apache. I
wrote an Apache plug-in which handles application launching, request
dispatching, and routing for our application environment for much
improved
scalability.
--
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.

--
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.

--
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.