Nathan,
What type of "scalability" are you looking for?
I'm too new to all of this to put up a good counter-argument. I don't want to pretend to know more than I do. I am aware that other technologies can scale, and that Node is not a silver bullet or "the" technology that everyone should use.
However, it seems to me that businesses like Walmart, eBay, Pay Pal, LinkedIn, Uber, Netflix, Groupon, and Yahoo could have chosen to deploy with Java, PHP or .NET if they had wanted to do so. It also seems to they could have chosen to deploy on IBM i systems if they had wanted to do so. Yet, they didn't. They chose Node.
I'm not going to speak on their behalf. I'm only going to say that, based on what I've read online, one reason they chose Node is because it scales very well. I'm also under the impression that our business wants the ability to scale to similarly large volumes of online business. So, I guess, that kind of scalability.
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: Saturday, March 17, 2018 11:33 PM
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Subject: Re: [WEB400] [EXTERNAL] Re: Rise of Node
Kelly,
Your assertion about Node.js "scalability" merits some clarification. That
assertion is valid in a couple of contexts. But not in others. The Node.js
event loop enables a single thread to manage thousands of socket
connections. If those connections are not doing much work, then that is a
specific case where the scalability claim is valid. The programmers who
wrote Node.js contrast the way that Node.js handles sockets with other HTTP
servers, which instantiate one thread for each socket connection, which is
a comparatively high resource utilization per socket.
The other context is when people talk about deploying Node applications to
a cloud hosting company that offers "elastic" scalability, which
essentially means deploying multiple instances of an application across a
server farm and using load-balancers to dispatch requests to a pool of
active Node.js instances. The problem with that type of "scalability" is
the cost.
Contrast that with the idea of deploying a complex ERP-class system on IBM
i. By ERP-class system, I mean one that might have a thousand database
tables, thousands of interactive applications and reports, batch processes,
and other types of workloads. Then asking IBM i to scale that "system" to
thousands or tens of thousands of concurrent users.
I hope that you can appreciate the distinction in how the term
"scalability" is used in the sense of a traditional ERP-class system. Under
IBM i, each user may be connected to and running 1-2 interactive sessions
(each session manages individual user state), and the platform may be
supporting tens of thousands of concurrently active Jobs. The platform just
handles it. Other platforms can't.
Back to talking about Node.js. It's well known that the Node.js event loop
runs in a single thread. Would that thread handle thousands of interactive
applications and reports (which is consistent with ERP-class systems), and
support thousands of concurrent users? No Way! It wouldn't even handle the
JavaScript logic required to "route" the requests for the appropriate users
to the appropriate applications; let along manage the "state" of individual
user sessions; let alone handle the callbacks that generate client
responses.
What type of "scalability" are you looking for?
On Sat, Mar 17, 2018 at 11:11 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx<mailto:KCookson@xxxxxxxxxxxx>>
wrote:
On the comparison of adopting Node and Java...
My shop refused to adopt Java on the IBM i because: (1) we were already
using .NET, and (2) database drivers and stored procedures were sufficient
for the few times we needed to make .NET interact with DB2 and COBOL.
Node is different for our shop for a variety of reasons.
* Using Node would let our .NET developers stop using ADO.NET to
interact with the IBM i. Getting rid of dependency on ADO.NET would let
them move to .NET Core.
* Node uses one of the de facto standard languages of the Internet:
JavaScript. People need to get over bad impressions they may have formed in
olden days. JavaScript (actually ECMAScript now) has matured quite a bit as
a language. And TypeScript offers enhancements if you want/need them. I am
NOT saying JavaScript is the best language ever. I AM saying we already
have people in our shop who have coded JavaScript for years.
* Node has proven scalability. It is used by businesses that need
to handle very high volumes of concurrent requests as fast as possible
while keep CPU *relatively* low. Businesses like Walmart, PayPal, eBay,
LinkedIn, Netflix, Dow Jones, and others use Node because it helps them
scale well. Our company has reasons for wanting the ability to scale very
big, too. I am NOT saying other technologies don't scale (they do). I AM
saying a lot of big businesses are choosing Node as a technology to help
them scale very big-and Node has proven successful for them. We are leaning
towards doing the same.
I don't know if I see Node replacing ILE languages in our shop. I tend to
think of Node as a niche technology. Use it when you need to process high
volumes of concurrent requests really fast while keeping CPU relatively
low. I'm not under the impression that Node/JS was intended to be a general
purpose programming platform like .NET or Java or CL/RPG/COBOL/C. I'm not
sure why I would use Node for a batch program that runs over a large number
of DB2 records to spit out a report. I'll keep an open mind. But someone
would have to persuade me.
Thanks,
Kelly Cookson
IT Project Leader
Dot Foods, Inc.
217-773-4486 ext. 12676
www.dotfoods.com<http://www.dotfoods.com><http://www.dotfoods.com<http://www.dotfoods.com>>
--
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>.
midrange.com
