Re: Question about Node.JS and XMLSERVICE

What is Node especially well suited for? It's gaining a good reputation as an

HTTP server, but what about responding to requests for static content?

Nathan, I am commenting mostly on the ones I know to expound on and not
ones that are more obvious (i.e. Node.js can produce HTML/json/XML with
ease) with very little research/experience.

Concerning static content, that's something the SO** community has been
debating for awhile. Basically, Node.js can serve static but apparently
nginx does it better. With that said, Node.js can do the same(sendfile)***
but I don't know if it is currently implemented in the frameworks (i.e.
ExpressJs).

**
http://stackoverflow.com/questions/9967887/node-js-itself-or-nginx-frontend-for-serving-static-files
***http://blog.std.in/2010/09/09/using-sendfile-with-nodejs/

As to what Node.js is particularly suited for... many people will respond
it is good at "networking things". Maybe a better way to look at it is to
compare it to other language heritages. For example, Ruby started as a
general purpose language and is now used prominently as a web language.
Ruby doesn't have the same call-back finesse as Javascript(Node.js), and
Javascript doesn't have the same general purpose ease-of-use of Ruby.

Concerning implementing business rules, I think we are going to see some
changes in Javascript on this front. For example, Javascript has been
plagued with modular inefficiencies over the years - to the point where
prominent groups have made up their own (i.e. requirejs.org, amdjs**,
commonJs). I believe ES6*** will start solving some of these issues,
though I haven't delved into the ES6 spec much because browsers don't
yet/all support it (to my knowledge).


**http://bit.ly/1JCaTji
***http://benmccormick.org/2015/05/28/moving-past-requirejs/

The database ones you listed, I think, are largely dependent on the quality
of the Node.js DB2 driver/adapter, which is written in C and goes directly
against the DB2 for i SQL CLI APIs. I have not had the opportunity to see
if functionality is missing (i.e. is the full SQL CLI API set
implemented). Node.js lacks a database abstraction layer for DB2 for i
(i.e. Waterline). And even with Waterline I don't believe it is nearly as
refined as Rails' ActiveRecord (though I am sure it will catch up). With
that said, it seems the database of choice in MANY Node.js tutorials is
MongoDB (or other document-minded database).

Concerning data integrity constraints, my opinion is those should be
implemented in the database including dependent deletes. With that said, I
sometimes implement them in my Ruby code because it is quick and easy
(naughty of me, I know).


So, Node.js can do all the above but I think what we need to further ask is
how well does it do them in relation to machine performance and developer
productivity, right? For a number of years now I've put a 70/30 split on
developer productivity over performance. By that I mean I do believe being
mindful of performance is necessary, but lost business opportunities are
more expensive, and those happen because developers can't build systems
that customers (internal and external) require in quick enough fashion.

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


On Fri, Aug 28, 2015 at 1:36 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

I think to answer this question you need to convey the various workload
options we have to pick from.

Fair enough. On the IBM i platform, I generally think of workloads
pertaining to broadly-scoped ERP class systems which entail hundreds to
thousands of DB tables, views, etc., which may be manipulated, queried, and
maintained by thousands of procedures (call them functions or methods),
which are packaged into cohesive units (call them programs, service
programs, or classes), which are organized into functional areas (finance,
human resources, distribution, etc.).

On this list (Web400) I generally think of workloads which include HTTP,
FTP, SMTP, and any other protocols which use the Internet.

My point in beginning with that type of context is intended to suggest that
application architecture matters.



Another way to break down Web application workloads might include:

1. Handling HTTP requests which may include requests for dynamically
generated content in addition to static.

2. Dispatching requests to appropriate handlers, taking into account that
broadly-scoped systems would have thousands of handlers.

3. Parsing HTML forms, query string parameters, XML and JSON input, browser
cookies, environment variables.

4. Generating HTML stream files (reports).

5. Generating PDF stream files.

6. Merging DB data with HTML, XML, and JSON responses.

7. Generating HTML, XML, and JSON responses.

8. Running DB queries and stored procedures.

9. Performing DB transactions and basic updates.

10. Implementing data validation and data integrity constraints.

11. Implementing business rules (ie. updates to one table may trigger
updates to others).

12. Interactive I/O may trigger submits to longer-running batch work.

What is Node especially well suited for? It's gaining a good reputation as
an HTTP server, but what about responding to requests for static content?
--
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.