I should not have used the term "node.js function" because it is confusing. I am talking about node.js modules.
I the Renaissance world the node.js HTTP server receives an request (which is basically a data model in JSON format). Part of the request dictates what node.js module in the application should be called to handle it. The call is not made directly, but is placed onto a queue. In the RPG world it is a data queue. In our node.js world it is a queue based on Redis (various libraries exist for this - we use BusMQ). A completely separate node.js process that knows nothing about HTTP picks the request off the redis queue and hands it off to the node.js module that is supposed to deal with it. The module then returns a response back to the redis queue, is picked up by the HTTP server and returned to the browser. So your application code can be completely separate from the HTTP server, and it can be divided up into nice manageable modules in the same way that you would in the RPG world. It can and is even managed by a completely different Git repo that the http server framework code that front ends it.
Each module follows the exact same template, e.g.
/***** BEGIN LICENCE BLOCK ***************************/
/* The initial developer of the code is "CoralTree */
/* Systems Ltd:
http://www.coraltreesystems.com */
/* */
/* Portions created by "CoralTree Systems Ltd" are */
/* Copyright (c) 2005-2016 CoralTree Systems Ltd. */
/* All Rights Reserved. */
/***** END LICENCE BLOCK *****************************/
/**
* @Module example
* @Description Renaissance function example
* @Author My name
* @Date
*/
/********************************************************************
/*
/* Modification log
/* ================
/*
/* Inits Date Modification
/* ===== ==== ============
/*
/********************************************************************/
module.exports = {
/**
* Globals
*/
me: Utility.getName(module),
dataout: {},
datain: null,
action: null,
MOD: null,
SES: null,
Func: null,
/**
* @name run
* @method
* @description Main procedure
* @param {Object} datain The inbound data
* @param {Object} A map of handles to Framework objects
* @param {Function} cb Callback
*/
run: function(datain,handles,cb) {
var self=this;
self.MOD=handles.MOD;
self.SES=handles.SES;
self.Func=handles.Func;
self.datain=datain;
self.action=datain.action.toLowerCase();
try {
// Initialise the function
this.initialise(datain,function(err){
// If we have an error then pass it back to the client
if (err) {
self.dataout.err=err;
self.finalise(function(err){
cb(self.dataout);
});
}
else {
// Process data model
self.process(function(err){
if (err) self.dataout.err = err;
// Finalise matters and run the callback
self.finalise(function(err){
// Pass back the payload and the delta model
if (err) self.dataout.err = err;
cb(self.dataout);
});
});
}
});
}
catch(err){
// Oops!
self.dataout.err=err;
self.finalise(function(err){
cb(self.dataout);
});
}
},
/**
* @name initialise
* @method
* @description Initialisation
* @param {Object} datain The inbound data
* @param {Function} cb Callback
*/
initialise: function(datain,cb){
var self=this;
self.MOD.initialise(self.me,datain,(self.action=="init"),function(err){
// If we have an "err" then pass it back
if (err) {
cb(err);
}
else {
// Clear out the messages
self.MOD.Message.initialise();
// Do local initialisation here
//.....
// Run the callback
cb();
}
});
},
/**
* @name process
* @method
* @description Process the data
* @param {Function} cb Callback
*/
process: function(cb){
var self=this;
try {
switch (self.action) {
case "init":
// . . . . Do stuff
// Run the callback
cb();
break;
case "get":
// Get stuff from the model
var foo=self.MOD.get("bar");
// Set stuff in the model
self.MOD.set("foo","bar");
break;
case "set":
// Get stuff from the model
var foo=self.MOD.get("bar");
// Set stuff in the model
self.MOD.set("foo",{
hello: "world",
bar: "baz",
});
// Run the callback
cb();
break;
default:
// Run the callback
cb();
break;
}
}
catch(err) {
cb(err)
}
},
/**
* @name finalise
* @method
* @description Finalise the function
* @param {Function} cb Callback
*/
finalise: function(cb){
var self=this;
// Perform any local tidy up here
//.....
// Finish off. VERY IMPORTANT!
self.MOD.finalise(cb);
},
};
[
https://www.netcracker.com/assets/img/netcracker-social-final.png] ƕ
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: 16 December 2016 14:51
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Subject: Re: [WEB400] Using Node w/ Apache
Thanks for your response, Keven. No, my question about running one Node instance per application (including one HTTP server instance) was not rhetorical. Nor do I know the answer to how one might deploy hundreds of "Node" applications, where the scope of an "application" is say 3-12 requests (i.e. insert, update, delete, read, etc.).
If you don't mind, what is your definition of "a node.js function". I gather that you're not referring to a JavaScript function.
The following blog provides context for my question:
http://blog.modulus.io/build-your-first-http-server-in-nodejs
It describes using Node to implement an HTTP request/response event loop
where:
1. An HTTP server listens for new requests.
2. New requests are forwarded to a "dispatcher" when they arrive.
3. The dispatcher invokes various named JavaScript functions to process each type of request.
4. A response is generated in the function to which requests are dispatched.
That blog example is somewhat simplistic in that the JavaScript functions to which requests are dispatched to don't implement dispatch-callback logic of their own. But it is typical of the types of node.js application samples that one sees on the Internet.
You say that "You can plug in any number of applications...". I really don't understand what you mean by that - other than you saying that "applications" don't need to implement an HTTP server.
Nathan.
On Fri, Dec 16, 2016 at 1:35 AM, Kevin Turner < kevin.turner@xxxxxxxxxxxxxxxxxxxx> wrote:
I guess your question is rhetorical because you probably know the
answer - and yes it does kinda depend on your definition of
"application". I don't really like the statement "node.js has a built in http server capability"
even though I may have said it myself. This gives the noob reader the
impression that every time they write a node.js function it is "http
server" ready but of course it isn't. A node.js module is only capable
of handling http requests if it "requires" the other modules it needs
and is then coded to do so. It is only built-in because you don't have
to have previously installed any extra packages using npm. It's a bit
like saying that RPG has built in SQL capability - that doesn't mean
that every RPG program you write uses SQL.
For my sins I completely rewrote the server side element of our
Renaissance Framework in node.js and only one part of that deals with
http requests from the client. You can plug in any number of
applications and all they deal with is the handling of inbound and
outbound data in JSON format. When a programmer develops a CRUD
application/function for the customer master file, they only care
about two things - the receipt and handling of the inbound JSON data
and the creation and return of the outbound JSON data. The fact that
this eventually gets delivered to an http client is of zero
consequence. These functions/applications have no http server capability at all.
Sent from my iPad
--
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.
________________________________
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
midrange.com
