|
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-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/<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-apps>
-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-se>
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<mailto:richard.schoen@xxxxxxxxxxxxxxx%3cmailto:richard.schoen@xxxxxxxxxxxxxxx>>
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@xxxxxxxxxxxx%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:opensource@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:OpenSource@xxxxxxxxxxxx%3cmailto:OpenSource@xxxxxxxxxxxx>>
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/opensource<https://lists.midrange.com/mailman/listinfo/opensource><https://lists.m
idrange.com/mailman/listinfo/opensource<http://idrange.com/mailman/listinfo/opensource>>
or email:
OpenSource-request@xxxxxxxxxxxx<mailto:OpenSource-request@xxxxxxxxxxxx<mailto:OpenSource-request@xxxxxxxxxxxx%3cmailto:OpenSource-request@xxxxxxxxxxxx>
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>>.
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.
midrange.com
