RisingStack surveyed 539 Node developers about using Node. They said the hardest thing to get right with Node is asynchronous programming. I'm new, but I know that asynchronous programming is key to leveraging Node's reactor pattern (event loop) architecture.
Here is the survey:
https://blog.risingstack.com/why-developers-love-node-js-2018-survey/
For those on this list who might not understand how an event loop works, here is a good video on browser event loops:
https://www.youtube.com/watch?v=8aGhZQkoFbQ
The event loop in Node works in a similar way, though it is implemented with different technology (e.g., Node uses libuv instead of web apis to manage the worker threads). Hopefully this video helps explain why asynchronous programming is so important with an evet loop.
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 Aaron Bartell
Sent: Tuesday, March 20, 2018 8:15 AM
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Subject: Re: [WEB400] [EXTERNAL] Re: Rise of Node
Otherwise async is a pretty cool feature for other things, but not
everything.
Agreed, use it where it makes sense to fill a programming need.
but when IBM switched to async and stopped updating or supporting the
sync db functions I think it's a mistake.
I think it's important to realize ~why~ this was done.
The sync approach was blocking the event loop from allowing other things to
run. This meant that you would have to do Node.js Clusters to accomplish
concurrency. Moving to asynchronous callbacks allowed the event loop to be
freed up because the DB call was being done in a separate thread in the
same IBM i job. The unfortunate part is we didn't get async/await keywords
at the same because they weren't yet available (Node.js foundation released
v8.x in June 2017 I believe).
We still have the sequential feel with the introduction of async/await,
which is what I believe you're really after. As show in this repo:
https://bitbucket.org/litmis/nodejs-idb-pconnector<
https://bitbucket.org/litmis/nodejs-idb-pconnector> (notice the 'p' in the
name, which stands for "Promises").
Aaron Bartell
IBM i hosting, starting at $157/month. litmis.com/spaces<
http://litmis.com/spaces>
On Tue, Mar 20, 2018 at 8:04 AM, Bradley Stone <bvstone@xxxxxxxxx<mailto:bvstone@xxxxxxxxx>> wrote:
On Mon, Mar 19, 2018 at 7:24 PM, Nathan Andelin <nandelin@xxxxxxxxx<mailto:nandelin@xxxxxxxxx>>
wrote:
I'm curious too. Particularly if the "batch script" were performing any
DB
I/O. Why would you do that in Node.js?
I'm in the same camp here with async operations for most DB, especially
retrieving data. I hear the argument "but your program can go and do this
and that while the result set is being retrieved". That's the whole
point.. I need that result set before I can continue on! :)
Updating, inserting and deleting for the most part can be anynch, but when
IBM switched to async and stopped updating or supporting the sync db
functions I think it's a mistake. Especially if you're doing business
programming.
Otherwise async is a pretty cool feature for other things, but not
everything.
--
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>.
--
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
