Nathan,
To pick up from another thread (your last post provided below), here is what I mean by a sub-app or a module:
https://www.youtube.com/watch?v=CJYCLuUD3_0
Maybe sub-apps is a poor choice of terminology on my part. Maybe module is the better term.
I was thinking this could be used to help create hierarchies of routes. So, an apache web server on the IBM I serves as a reverse proxy. A user sends a request to the apache web server. The apache web server routes the request to a node app listening on port 8787 of the IBM i. The node app then routes the request to the module that processes the request and returns a response.
For example, we currently have a handful of 5250 green screens and underlying COBOL programs that carry out five functions in our prepayment process:
* display orders that require credit card or wire transfer prepayment
* request prepayments for one or more orders by email (some customer place multiple orders)
* track whether or not prepayments have been received from customers
* re-date orders when payments are not received in time to meet the delivery date
* cancel orders on customer request
Our employees call the programs as needed over a period of several days to manage the prepayment process. I could create five node apps listening on five unique ports--one for each of the functions. But then I would need five reverse proxy routes in my web server. Alternatively, I could create five modules inside one node app listening on one port. This way, I would only have to set up one reverse proxy route in my web server. The one node app would have a start page from which employees could get to the module they need.
On a different note: I was also considering having a reverse proxy route in a web server that sends requests to a node app on, say, port 8787. The node app listening on port 8787 could then use node-http-proxy or vhost to route the requests to other node apps listening on their own unique port numbers. But it does add an extra layer of routing (web server > node app using node-http-proxy or vhost > node app that processes request), and it might mean more opportunities for bugs and gotchas. So I'm having second thoughts about this approach.
BTW, when it comes to web and mobile development, I guess I think of a "node app" as JavaScript code that runs on node and listens on a unique port. A node app could function purely as a reverse proxy, if you didn't want to use a web server. Or a node app could process requests and return responses. I don't think this is general way to think of node apps, since I don't know how well it extends to JavaScript code using web sockets, and since JavaScript code might not have anything to do with web or mobile development (e.g., JavaScript code running in node could do nothing more than manipulate text files in the IFS). I'm open to hearing about other ways to conceptualize what a "node app" is.
Thanks,
Kelly Cookson
IT Project Leader
Dot Foods, Inc.
1.217.773.4486 ext. 12676
kcookson@xxxxxxxxxxxx
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Thursday, October 15, 2015 6:43 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Hosting a Large Number of Node Apps on the IBM i
A developer can also create "sub-apps" or modules within a "node app"
using ExpressJS router and module.exports. "Sub-apps" do not have
their own port numbers.
Here's a little bit of trivia; when I click on the link to "expand" this conversation in Gmail, it leads to a 1.8 Megabyte download. Maybe someone should start a new thread ;-)
Kelly,
It appears to me that the idea of "sub-apps" in Express.js is a "router"
within a "router". A "sub-app" is NOT an otherwise functional application, if I understand correctly.
Given the already obscure interface exposed by Express.js, their idea of "routers" within "routers" or "apps" within "apps" becomes even less clear.
They use regular expressions including wild-card characters to compare "routes" to URL "paths" which is another difficult concept. There is quite a bit of "overhead" in matching URLs with regular expressions.
After more thought, I'm still hung-up on the "necessity" of restarting a Node.js service every time a routing configuration changes, which occurs with every new "functional application" that is added to the service (every new URL which is defined). We're adding new applications to our Web portal daily during "sprints".
The need for an external router which includes fail-over support would be an absolute requirement. When you combine "applications" with "routing" and "HTTP services" in a single process, developers come up with all kinds of unforeseen ways to bring down the entire lot. Maybe it's as simple as a condition that results in a continuous loop. And it's unclear what may have caused it.
It appears to me that Node.js is more suited for "simple" "applets".
--
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.
midrange.com
