× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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> On Behalf Of Vernon Hamberg
Sent: Monday, June 4, 2018 3:03 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

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'
}
};

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-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>

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<https://lists.m
idrange.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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.