As a complete newbie to node, I found this video useful in understanding what node is:
https://www.youtube.com/watch?v=L0pjVcIsU6A

It explains what the event loop in node is, and why it's important to node performance.

Understanding the event loop also helped me understand why node is an opinionated development tool. You *have* to use event loop programming. It is possible to develop JavaScript apps, web apps, and RESTful services without event loop programming. But, as soon as you want to do things using node, it's event loop programming way or the highway. (Which is neither good nor bad in itself...it depends on the circumstances, as always.)

I'm sure this is all old news to those already familiar with node.

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Kevin Turner
Sent: Thursday, August 27, 2015 6:06 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Question about Node.JS and XMLSERVICE

Yes Nathan - you cannot code things in a node application that "block" because it interrupts the event cycle and the node app just hangs. In my case I want to wait for entries (of a certain key) on a data queue - and you cannot embed functionality like that without blowing node out of the water. Instead I fork a child process to do it which sends messages back to the main app as relevant items appear on the queue.


On 27 Aug 2015, at 23:31, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Thanks for your replies, Aaron and Kevin.

Aaron, there was a tickle in the back of my brain of there being an
additional interface to XMLSERVICE via Node.js DB access. But the dots
were not connecting in my mind. I found the following reference which
corroborates the information you shared:

https://www.ibm.com/developerworks/ibmi/library/i-native-js-app-ibmi-w
ith-nodejs/

Figure 2. Node.js for IBM i infrastructure, was particularly illustrative.

I'll assume for the moment that the diagram labeled "Node.js Toolkit
for IBM i" uses the XMLSERVICE REST Web Services interface. As an
alternative it seems pretty clear that the diagram labeled "DB2 for i
Access Library", uses the SQL CLI interface.

I'd like to throw out another question. In my experience, complex
business applications rely quite a bit on the "state" of database
tables being maintained for paging and other purposes. How would one
manage database state under Node.js?

Kevin, your comment about pulling data off a data queue and handling
"blocking" issues with child processes sounds interesting. If I
understand correctly you're expressing a concern about "blocking". But
I don't understand the part about child processes.

I thought I read somewhere that although Node.js runs under one
process, it uses threads internally, so that say DB I/O blocking does
not adversely affect its handling of multiple concurrent HTTP
connections. Or is there a problem?






On Thu, Aug 27, 2015 at 2:10 PM, Aaron Bartell
<aaronbartell@xxxxxxxxx>
wrote:

You are correct, you don't *need* Apache. Apache is just one way to
get around the DB2foriAccess blocking issue (or dataqueue blocking,
in your case). Good idea on using child_process. I wonder how well
a database connection would work doing the same. Or maybe even a guy
could route an entire request from start to finish to their own
child_process (effectively an IBM i job) as a means to release the
primary Node.js thread to receive in the next connection. That's
potentially a lot of jobs :-( That's one advantage of the Apache
approach is the Node.js processes wouldn't end and instead stay "alive" to process the next request (a lot like RPG CGI).

A complete side note, though on the blocking/non-blocking topic...

The following book helped me gain perspective on how and when things
in Node.js becoming blocking in nature. The book is more like a long
article and is a quick read. The guy had a lot of the same questions
I had and cleared up a lot of questions.

http://bit.ly/node-beginner-book-manuel-kiessling



Aaron Bartell
litmis.com - Open Source and IBM i. No Limits.


On Thu, Aug 27, 2015 at 2:56 PM, Kevin Turner <
kevin.turner@xxxxxxxxxxxxxxxxxxxx> wrote:

I am using node.js and the IBM I toolkit and there is no Apache code
in the mix as far as I know. I am running a node server that pulls
data off
a
data queue. That is also a blocking process so I am using a child
worker
to
do the job (basically a thread) using child_process.

On 27 Aug 2015, at 21:15, Aaron Bartell <aaronbartell@xxxxxxxxx>
wrote:

​You are correct that XMLSERVICE can be used in two ways - database
stored
procedure and REST HTTP calls.

When doing 1-tier scenarios (i.e. Node.js is on same IBM i as the
DB2
you
are after) then the stored proc approach is best (a lot faster).
If
2-tier
(Node.js is running on Linux or other) then the REST HTTP approach
can
be
used.

The XMLSERVICE DB stored proc approach is using the Node.js DB2
adapter which is written in C and calls the SQL CLI APIs directly.
There is no ODBC or JDBC or MySQL layer in-between.

Here's the scenarios I have for calling RPG and accessing DB2,
respectively:
Browser<==>Apache<==>Node.js/Ruby<==>toolkitfori**<==>RPG
Browser<==>Apache<==>Node.js/Ruby<==>db2foriaccess***<==>DB2

It's worth nothing that Apache isn't required in all circumstances,
though
right now it is somewhat a necessity since the DB2foriAccess for
Node.js
is
blocking.

**http://bit.ly/nodejs_toolkitfori
***http://bit.ly/nodejs_db2foriaccess

What type of application code do you run under Node.JS?
What type of application code do you run under IBM i programs and
procedures?

This is where opinions can greatly differ, and I will offer up mine...
- You get significantly faster development if your
<open-source-language>
can go directly to the DB. Here's where some will say "I don't
trust
those
Node.js devs, so they have to obtain all of their data via calls to
RPG".
Big productivity killer. Big slow-down in finding bugs. etc.

- It is wise to re-use existing RPG business logic because
rewriting
can
take long enough that the time savings of going with
<open-source-language>
would be lost. The toolkitfori (aka the XMLSERVICE interface for
Node.js)
is an excellent stop-gap. My customers have a mix of logic in
<open-source-language> and RPG.

- How much logic you put in <open-source-language> depends a lot on
the shop's future direction. For example, I have some customers
that have determined <open-source-language> is their new direction
and will eventually replace the majority of their existing code
base. This
leads
them to leverage existing RPG with XMLSERVICE *sometimes*, but a
lot of logic is being put into <open-source-language>.

- <open-source-languages> have excellent packaging capabilities
(think *SRVPGMs on steroids). For example, you could keep your
Node.js Order Processing business logic in a Node Package Module
(npm) and store it
in
a
private repository. Then in your apps you could simply include
that
Order
Processing npm in the package.json file as an application
dependency
that
gets installed and updated in simple fashion (i.e. npm install
order_processing, npm update order_processing).

- It's very interesting to read about Walmart Labs and how they've
approach
adoption of Node.js. They have the same legacy issues as the IBM i
base
(their legacy is old-school Java Struts/Servlets from 10+ yrs ago).


Very good questions. These are the types of things every shop
adopting open source needs to ask and spend some time doing tests.


Aaron Bartell
litmis.com - Open Source and IBM i. No Limits.


On Thu, Aug 27, 2015 at 1:33 PM, Nathan Andelin
<nandelin@xxxxxxxxx>
wrote:

My understanding is that XMLSERVICE provides 2 interface options
for various language environments:

1. XMLSERVICE via. ODBC / JDBC stored procedure calls (DB2 Interface).

2. XMLSERVICE via IBM i Apache-CGI calls (REST Web Service Interface).

Since Node.js has an excellent reputation for supporting socket
I/O,
I'll
assume for the moment that the IBM i implementation makes calls to
XMLSERVICE via the REST Web Service Interface. But does anyone
know
for
sure?

The flow in my mind goes as follows:

Browser <==> Node.JS HTTP & Application Interfaces <==> IBM i
Apache Interface <==> XMLSERVICE CGI <==> IBM i SQL and PGM resources.

Does that sound about right?

If so, what would be good guidelines for structuring applications
under
this flow?

What type of application code do you run under Node.JS?
What type of application code do you run under IBM i programs and
procedures?
--
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 email has been scanned by iomartcloud.
http://www.iomartcloud.com/

________________________________

NOTICE: The information in this electronic mail transmission is
intended by CoralTree Systems Ltd for the use of the named
individuals or entity
to
which it is directed and may contain information that is privileged
or otherwise confidential. If you have received this electronic mail
transmission in error, please delete it from your system without
copying
or
forwarding it, and notify the sender of the error by reply email or
by telephone, so that the sender's address records can be corrected.
---------------------------------------------------------------------
-----------


CoralTree Systems Limited
Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton
Hampshire
SO15 2EA
VAT Registration Number 834 1020 74.
--
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.


___________________________________________
This email has been scanned by iomartcloud.
http://www.iomartcloud.com/


________________________________

NOTICE: The information in this electronic mail transmission is intended by CoralTree Systems Ltd for the use of the named individuals or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone, so that the sender's address records can be corrected.



--------------------------------------------------------------------------------


CoralTree Systems Limited
Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton
Hampshire
SO15 2EA
VAT Registration Number 834 1020 74.
--
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 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-2020 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].