Re: [IBMiOSS] Ports and routes needed to replace very large numbers of green screens

Kelly,

Not sure if Alex Roytman or any of his team monitors this group. I'm pretty sure they watch it.

Maybe they can venture a response on their thoughts on multi-app scaling on a single port with Node since they are in the business of IBMi UI modernization with Node.

Aaron Bartell also watches this as well I think and I haven' seen him weigh in yet.

Since Node is not my full time development vehicle of choice I can only say right now that you have a valid concern.

If we're talking an Apache server or Nginx or IIS I'm pretty sure those web servers can handle the scaling/routing just fine.

Not sure about node apps where they might are self-hosting JS apps. I've been able to crash my Node sample servers before.

One other thought which I think you mentioned would be to use an individual port for app groups with a smaller amount of routes and then use a proxy server front end to route to the appropriate ports accordingly based on a top level port such as 443. This would possibly give a middle ground approach.

Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com

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

message: 1
date: Mon, 4 Jun 2018 14:02:30 -0500
from: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
subject: Re: [IBMiOSS] [EXTERNAL] Re: Ports and routes needed to
replace very large numbers of green screens

Kelly

I"m coming in late and probably a bit ignorant of some things.
Nonetheless, I do know a little about the Apache web server on i.

So I'm thinking about how Profound UI handles things - I believe the connections are 1 per user - all going to port 80 (or whatever you set
up) in the Apache server. The HTTP server starts separate prestart jobs for each connection. There would be different remote ports for each client, right? Those are negotiated, as I understand it, by the Apache server and the client.

When using CGI stuff with programs in a library, you have a directive that points to that library, and any program, can be called - so you need only 1 port for that to take place.

Does that approach line up with the node.js concept you are looking at?
Are you using the built-in Apache server as the web server? I assume you would basically be using a single node.js process at a time, for each screen or set of screens.

Anyhow, just an outside thinker on all this - I hope any of this is sensible and helps.

Cheers
Vern


On 6/4/2018 1:45 PM, Kelly Cookson wrote:

Thanks again Richard.



I assume that replacing many hundreds of green screen apps (many
hundreds of interactive COBOL programs with DSPF screens) with web
pages will require many hundreds of web apps or many hundreds of web
services. If this assumption is wrong, please correct my thinking. I
would welcome an alternative approach. :)



Information in google searches typically assume you have a small number of apps (2 or 3 apps). They tend to recommend one of two basic strategies:

1. Have your apps listening on different ports, then have a web server act as a reverse proxy. All requests are made to the reverse proxy, which then routes the requests to the appropriate port on which an app is listening.

2. Have one Node.JS web server, then use routing supplied by a framework like Express. You only have one web server listening on one port. But you have a lot of internal routes so that the appropriate app is run when a request is made.

I know I could use lots of ports to host lots of apps/web services. I know I could use reverse proxies and internal routing (e.g., with Express) to host lots of apps/web services. The question is, when we have many hundreds of apps/web services to host, what are the best strategies to use in terms of user performance and IT maintenance?

For example, I used your suggested search phrase: multiple node.js apps on same port.

The first page I reviewed was:
https://stackoverflow.com/questions/11225983/running-multiple-node-exp
ress-apps-on-same-port?utm_medium=organic&utm_source=google_rich_qa&ut
m_campaign=google_rich_qa

Based on the page linked above, one way is to use the app.use() functionality in the Express framework. This is kind of what I meant by routing, though this may not be the actual "routing" functionality that comes with Express.

app
.use('/app1', require('./app1/index').app)
.use('/app2', require('./app2/index').app)
.listen(8080);

But what happens when I have many hundreds of apps? That is, what happens when I have many hundreds of lines that look like:
.use('/app942','require('/app942/index').app)
Will it slow down performance to a crawl? Will all of the apps go down if one app crashes? Do developers have to scroll through a list of many hundreds of apps to make a change (e.g., rename an app or delete an app)? Am I locked into the Express framework now because I'm using its app.use() functionality? Is this really a viable approach?

Another option on the same page was to have lots of apps served through one reverse proxy.

You could run them as separate apps listening to different ports and then have a proxy (like https://github.com/nodejitsu/node-http-proxy/ ) serving everything on 8080 depending on the requested URL. like:
var options = {
router: {
'foo.com/baz': '127.0.0.1:8001',
'foo.com/buz': '127.0.0.1:8002',
'bar.com/buz': '127.0.0.1:8003'
}
};