|
On Jun 4, 2018, at 4:56 PM, Slanina, John <jslanina@xxxxxxxxxx> wrote:
Question ? How many sites allow users or subscribers to connect to IBM I Apache Instance ? None of our users or subscribers every connects directly to the IBM I Apache Instance.
Thanks
John Slanina
-----Original Message-----
From: OpenSource <opensource-bounces@xxxxxxxxxxxx> On Behalf Of Kelly Cookson
Sent: Monday, June 4, 2018 3:42 PM
To: IBMi Open Source Roundtable <opensource@xxxxxxxxxxxx>
Subject: Re: [IBMiOSS] [EXTERNAL] Re: Ports and routes needed to replace very large numbers of green screens
Hi John,
I used to think Node.JS would provide better performance than CGI on the IBM i. However, based on conversations over at the WEB400 list, I've had a change of mind. It was pointed out to me that CGI performs better on the IBM i than it does on other systems. I am by no means an expert. But WEB400 got me looking into the IBM documentation, and I read enough to accept what the good folks at WEB400 were saying.
Now, under extremely large loads of concurrent requests, Node.JS might have an edge. But more than one person has told me that such extreme loads would be handled using multiple boxes, so performance with Node.JS still might not be any better than with CGI from a client's perspective.
I think the reasons for using Node.JS would be something other than performance (or web serving or routing). They would be things like:
* Having prior skills with JavaScript and Node.JS.
* Wanting the use the same programming language to develop the front-end and back-end of web apps.
* Wanting to use popular frameworks like Express or Electrode.
* Wanting to use popular libraries and frameworks like React.JS, Angular, or Vue.JS to develop single page web apps.
* Wanting to use libraries or modules made available in npm.
If you're a .NET shop as well, then you can apply Node.JS skills to .NET web apps using Microsoft's JavaScript Services. JavaScript Services allow .NET web apps to use JavaScript functions and libraries that run on Node.JS under the covers. So, as one example, you could use the JavaScript library React.JS to develop single page web apps in .NET.
Finally, Microsoft, like IBM, is a platinum member of the Node.JS foundation. Both companies are invested in Node.JS technology. It is at least possible that Node.JS will becomes a technology that allows developers to work more comfortably in an environment that uses both IBM i and Windows systems.
Having said that, I think CGI and PHP and Java (and some other technologies) can be just as useful as Node.JS. We have a team looking at all of these options and more. I'm not trying to say that Node.JS is the best solution for everybody.
Thanks,
Kelly Cookson
IT Project Leader
Dot Foods, Inc.
217-773-4486 ext. 12676
www.dotfoods.com<http://www.dotfoods.com>
From: OpenSource [mailto:opensource-bounces@xxxxxxxxxxxx] On Behalf Of Slanina, John
Sent: Monday, June 04, 2018 2:10 PM
To: IBMi Open Source Roundtable <opensource@xxxxxxxxxxxx>
Subject: Re: [IBMiOSS] [EXTERNAL] Re: Ports and routes needed to replace very large numbers of green screens
I don't understand what node.js offers you when calling an api ? I have one CGI rpgle program that is called from my Apache Instance on the IBM I.
That does a database lookup to find what RPGLE program to call for that api , then passes then pass the JSON as a yajl_val and also returns an yajl_val.
One standard parm list for all my program.
Thank
John Slanina
-----Original Message-----
From: OpenSource <opensource-bounces@xxxxxxxxxxxx<mailto:opensource-bounces@xxxxxxxxxxxx>> On Behalf Of Vernon Hamberg
Sent: Monday, June 4, 2018 3:03 PM
To: IBMi Open Source Roundtable <opensource@xxxxxxxxxxxx<mailto:opensource@xxxxxxxxxxxx>>
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
<https://stackoverflow.com/questions/11225983/running-multiple-node-ex
p>
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/<https://github.com/nodejitsu/node-http-proxy/> ) serving everything on 8080 depending on the requested URL. like:
var options = {
router: {
'foo.com/baz<http://foo.com/baz>: '127.0.0.1:8001',
'foo.com/buz<http://foo.com/buz>: '127.0.0.1:8002',
'bar.com/buz<http://bar.com/buz>: '127.0.0.1:8003'
}
};
My .NET web clients would only need to make requests to port 8080 in an Apache web server on the IBM i. But now I'm running many hundreds of Node.JS (or PHP or whatever) web apps on their own ports. Those many hundreds of ports then have to be routed (e.g., 'foo.com/baz':'127.0.0.1.8001<http://foo.com/baz':'127.0.0.1.8001>'). So now I have both a ton of ports and a ton of routes. Is this really a viable strategy?
Another commenter on the page said:
Of course you can run your subapps wrapped in one app and handle the
routing internally. I personally just don't like my apps depend on
each other that much, when it comes to crashes. Thats why i prefer
running them on different ports
So again, we have the question of whether to have a lot of routes or a lot of ports, with at least one commenter preferring a lot of ports because routes create dependencies that are bad when one app crashes. Should that be the driving concern in all cases? If not, when would other concerns be more important?
The approaches above were also found on other pages I skimmed:
https://github.com/restify/node-restify/issues/1035<https://github.com
/restify/node-restify/issues/1035>
https://nerdpress.org/2012/04/20/hosting-multiple-express-node-js-apps
<https://nerdpress.org/2012/04/20/hosting-multiple-express-node-js-app
s>
-on-port-80/
http://jslim.net/blog/2014/03/14/running-multiple-nodejs-app-in-one-se
<http://jslim.net/blog/2014/03/14/running-multiple-nodejs-app-in-one-s
e>
rver-using-nginx/
I'm really struggling to find information on best practices or strategies for hosting many hundreds of apps/web services.
Thanks,
Kelly Cookson
IT Project Leader
Dot Foods, Inc.
217-773-4486 ext. 12676
www.dotfoods.com<http://www.dotfoods.com><http://www.dotfoods.com<http
://www.dotfoods.com>>
From: OpenSource [mailto:opensource-bounces@xxxxxxxxxxxx] On Behalf Of
Richard Schoen
Sent: Monday, June 04, 2018 12:43 PM
To: opensource@xxxxxxxxxxxx<mailto:opensource@xxxxxxxxxxxx>
Subject: [EXTERNAL] Re: [IBMiOSS] Ports and routes needed to replace
very large numbers of green screens
If you google the following you will gain some perspective:
multiple node.js apps on same port
Each app doesn't appear to require its own port necessarily.
Regards,
Richard Schoen
Director of Document Management
e.
richard.schoen@xxxxxxxxxxxxxxx<mailto:richard.schoen@xxxxxxxxxxxxxxx<m
ailto:richard.schoen@xxxxxxxxxxxxxxx%3cmailto:richard.schoen@helpsyste
ms.com>>
p. 952.486.6802
w. helpsystems.com
------------------------------
message: 3
date: Mon, 4 Jun 2018 17:37:19 +0000
from: Kelly Cookson
<KCookson@xxxxxxxxxxxx<mailto:KCookson@xxxxxxxxxxxx<mailto:KCookson@DO
TFOODS.com%3cmailto:KCookson@xxxxxxxxxxxx>>>
subject: Re: [IBMiOSS] [EXTERNAL] Re: Ports and routes needed to
replace very large numbers of green screens
Hi Justin,
Yeah, that's what I'm getting at.
If you look at Node.JS tutorials, they almost always create a simple app that is hosted in its own Node.JS web server (i.e., the web server functionality of Node.JS). If I use this model, and treat each web service as an independent Node.JS app running in its own web server, then I potentially end up with many hundreds of ports running Node.JS web servers. I know there is routing in Node.JS frameworks like Express. But then I get back to my question: do I want one Node.JS server with large numbers of Express routes in an initial gateway app? Or is there some balance between number of Node.JS web servers and Express routes that I should be aiming at? If so, what would be recommended? What's the target?
We would never do a big-bang approach where we actually tried to convert all of our green screen apps at once. But, once we get started, the number of conversions will grow over time. I would like to have plan in place for how we will manage them. I don't want to wait until it becomes unmanageable, then realize we painted ourselves into a corner and have to re-code everything.
Thanks,
Kelly Cookson
IT Project Leader
Dot Foods, Inc.
217-773-4486 ext. 12676
www.dotfoods.com<http://www.dotfoods.com><http://www.dotfoods.com<http
://www.dotfoods.com>><http://www.dotfoods.com<http://www.dotfoods.com>
<http ://www.dotfoods.com<http:////www.dotfoods.com>>>
From: OpenSource [mailto:opensource-bounces@xxxxxxxxxxxx] On Behalf Of
Justin Taylor
Sent: Monday, June 04, 2018 12:02 PM
To: IBMi Open Source Roundtable
<opensource@xxxxxxxxxxxx<mailto:opensource@xxxxxxxxxxxx<mailto:opensou
rce@xxxxxxxxxxxx%3cmailto:opensource@xxxxxxxxxxxx>>>
Subject: Re: [IBMiOSS] [EXTERNAL] Re: Ports and routes needed to
replace very large numbers of green screens
I share Kelly's concern about ports. How do people handle it? If I magically converted all our 5250 apps to Node apps, I'd have thousands of ports listening.
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list To
post a message email:
OpenSource@xxxxxxxxxxxx<mailto:OpenSource@xxxxxxxxxxxx<mailto:OpenSour
ce@xxxxxxxxxxxx%3cmailto:OpenSource@xxxxxxxxxxxx>>
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/opensource<https://lists.m
idrange.com/mailman/listinfo/opensource><https://lists.m
idrange.com/mailman/listinfo/opensource<http://idrange.com/mailman/lis
tinfo/opensource>>
or email:
OpenSource-request@xxxxxxxxxxxx<mailto:OpenSource-request@xxxxxxxxxxxx
<mailto:OpenSource-request@xxxxxxxxxxxx%3cmailto:OpenSource-request@mi
drange.com>
Before posting, please take a moment to review the archives athttps://archive.midrange.com/opensource<https://archive.midrange.com/opensource><https://archive.midrange.com/opensource<https://archive.midrange.com/opensource>>.
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list To post a message email: OpenSource@xxxxxxxxxxxx<mailto:OpenSource@xxxxxxxxxxxx> To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/opensource<https://lists.midrange.com/mailman/listinfo/opensource>
or email: OpenSource-request@xxxxxxxxxxxx<mailto:OpenSource-request@xxxxxxxxxxxx> Before posting, please take a moment to review the archives at https://archive.midrange.com/opensource<https://archive.midrange.com/opensource>.
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list To post a message email: OpenSource@xxxxxxxxxxxx<mailto:OpenSource@xxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/opensource<https://lists.midrange.com/mailman/listinfo/opensource>
or email: OpenSource-request@xxxxxxxxxxxx<mailto:OpenSource-request@xxxxxxxxxxxx>
Before posting, please take a moment to review the archives at https://archive.midrange.com/opensource<https://archive.midrange.com/opensource>.
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list To post a message email: OpenSource@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at https://archive.midrange.com/opensource.
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/opensource.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.