|
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-express-apps-on-same-port?utm_medium=organic&
utm_source=google_rich_qa&utm_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'
}
};
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'). 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://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-server-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>
From: OpenSource [mailto:opensource-bounces@xxxxxxxxxxxx] On Behalf Of
Richard Schoen
Sent: Monday, June 04, 2018 12:43 PM
To: 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>
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>>
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>>
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>>
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>
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/opensource<ht
tps://lists.midrange.com/mailman/listinfo/opensource>
or email: OpenSource-request@xxxxxxxxxxxx<mailto:OpenSource-request@
midrange.com>
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.
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
