I agree there are two topics. I was wondering whether or not there might be some decisions about routing strategies that impact the ability to scale apps.

Thanks,

Kelly Cookson
IT Project Leader
Dot Foods, Inc.
1.217.773.4486 ext. 12676
kcookson@xxxxxxxxxxxx

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Kevin Turner
Sent: Tuesday, October 13, 2015 3:11 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Hosting a Large Number of Node Apps on the IBM i

I think you have raised two separate and distinct topics there:
1) how to ensure scalability
2) how to address routing for different apps

The second topic is not unique to node apps. That would be a question to resolve for any multi-app browser based environment. There a many ways to skin that cat based on preference (different ports or virtual hosts etc).

The first topic is probably a relatively unknown given that there are not many of us doing it yet. I am working on the basis that I only need one suitably sized LPAR for all my current web apps, so I certainly wouldn't entertain anything else for node apps. If I have to start thinking about clustering or nginx etc for node to scale then it's a failure for me.

Sent from my iPad

On 13 Oct 2015, at 19:32, Kelly Cookson <KCookson@xxxxxxxxxxxx> wrote:

If our shop adopts node, we would probably use it to develop web and mobile apps instead of 5250 green screens (for future development). Over the years, we have accumulated a large number of 5250 green screen interactive programs. If we adopt node, I can imagine we will accumulate a similarly large number of node apps.

The way to host a large number of node apps is, according to my Google searches, routing. But there are different strategies for routing.

1. Use a reverse proxy to route requests to node apps, where each node app has its own URI and port number. The reverse proxy could be a web server or something like node-http-proxy. Redbird also appears to be a package for setting up a reverse proxy for node apps (https://github.com/OptimalBits/redbird?utm_source=nodeweekly&utm_medium=email).

2. Use ExpressJS vhost to route requests to node apps, where each node app has its own URI and port number.

3. Use ExpressJS routers and module.exports to route requests to node sub-apps or modules (something like this: https://vimeo.com/56166857).

So, I am left with a few questions. What strategy or combination of routing strategies would be best for ensuring high availability of node apps? What strategy or combination of routing strategies would be best for scaling node apps (e.g., using the cluster module)? Is reducing the number of unique ports being listened to by node apps a good reason for using the sub-apps strategy (option #3 above)?

Thanks,

Kelly Cookson
IT Project Leader
Dot Foods, Inc.
1.217.773.4486 ext. 12676
kcookson@xxxxxxxxxxxx

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan
Andelin
Sent: Tuesday, October 13, 2015 12:00 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Node.js vs. MS .Net Web Application Development


Is there a reason node's cluster module would not work on the IBM i?

I'm not aware of any reason that Node's cluster module wouldn't work on IBM i. But rather than writing code to add clustering into one's "application", my first inclination would be to launch multiple instances of the same application, with each answering on a different port. Use an external "proxy/load balancer" to route requests to each.

That's how most shops implement scaling on .Net too.

Although Node.js includes a built-in HTTP service, it makes more sense to me to pair it with an external proxy which would handle things like "caching" static files, gzip compression, encryption, request logging, request routing, etc.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.


___________________________________________
This email has been scanned by iomartcloud.
http://www.iomartcloud.com/


________________________________

NOTICE: The information in this electronic mail transmission is intended by CoralTree Systems Ltd for the use of the named individuals or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone, so that the sender's address records can be corrected.



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


CoralTree Systems Limited
25 Barnes Wallis Road
Segensworth East, Fareham
PO15 5TT

Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton, UK
SO15 2EA
VAT Registration Number 834 1020 74.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/web400.


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.