Hi Nathan,

That must be a stretch for a lot of developers, particularly traditional
IBM i developers who are accustomed to having the operating system
manage concurrency and the resource requirements of other processes.

Yes, I too think that asynchronous programming will be one of the biggest challenges for CL/RPG/COBOL programmers. How developers respond to that question will depend on the individual, of course. I see it as an exciting challenge—the way I enjoy solving a puzzle. But I can certainly understand other developers being put off by it.

In regard to your batch example, Node.js developers should be aware of the
additional overhead and latency added by using Node.js language constructs
that yield control to the event loop.

I tried clicking the link you offered, but I kept getting a 504 error. Maybe it’s my connection?

Although there may be some overhead associated with worker threads, businesses that use Node have often been able to handle more requests more quickly while reducing the number of servers they use. Here is a slideshow that mentions some examples:
https://www.slideshare.net/joemccann/the-business-case-for-node
Also, when Walmart put 55% of its Black Friday web traffic on Node, CPU usage hovered around 1%.

It’s not just asynchronous programming, though. You have know what you’re doing with Node and its modules to get these kinds of results. Netflix learned that the hard way:
https://medium.com/netflix-techblog/node-js-in-flames-ddd073803aa4

Thanks,

Kelly Cookson
IT Project Leader
Dot Foods, Inc.
217-773-4486 ext. 12676
www.dotfoods.com<http://www.dotfoods.com>

From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Tuesday, March 20, 2018 9:24 AM
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Subject: Re: [WEB400] [EXTERNAL] Re: Rise of Node

On Tue, Mar 20, 2018 at 12:54 AM, Henrik Rützou <hr@xxxxxxxxxxxx<mailto:hr@xxxxxxxxxxxx>> wrote:

An Await waits by transferring control to the event loop! How on earth
would node else continue to process other code waiting for resources.


Henrik,

I appreciate the thought you put into your message, and the detail. It
emphasizes that Node.js developers not only write code that implements
functional requirements, but they must also write code and use language
constructs that yield control to Node's event loop. Otherwise your code
would not play well with other processing that needs to be allowed to run.

That must be a stretch for a lot of developers, particularly traditional
IBM i developers who are accustomed to having the operating system manage
concurrency and the resource requirements of other processes.

In regard to your batch example, Node.js developers should be aware of the
additional overhead and latency added by using Node.js language constructs
that yield control to the event loop.

http://bit.ly/2FQZqCr<http://bit.ly/2FQZqCr>

In the case of reading files from the local file system, Node.js
async-await adds 10-25 times to complete the read cycle in comparison to
synchronous processes written in Python. Imagine how much longer that would
take if a batch process were working against a remote database which
entails not only reading from a file system, but add to that the
requirements of inter-system communications.

To me, that would be a strong case for using RPG to implement batch
processes against IBM i databases as opposed to force-fitting that into a
Node.js service.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx<mailto:WEB400@xxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400<https://lists.midrange.com/mailman/listinfo/web400>
or email: WEB400-request@xxxxxxxxxxxx<mailto:WEB400-request@xxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400<https://archive.midrange.com/web400>.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.