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



Nathan,

I do see the advantages of using a web server as a reverse proxy. Web servers have a lot of tools and extensions already built into them, and people have been using them to set up fail-over and load balancing for a while. Why try to re-invent the wheel inside a node app? I get this piece, I think.

The question that has me the most stumped is the one about "routing"
potentially thousands of URLs to appropriate JavaScript routines...

Yeah, me too. I'm thinking about using a mix of strategies to form hierarchies. Let me offer a hypothetical example (to be shot down as appropriate).

Each department in our company has its own web servers that function as reverse proxies for node apps. A user from the Credit department sends a request to use the "request credit card" portion of our prepayment node app. The request goes from the browser to the reverse proxy. The reverse proxy forwards the request to the prepayment node app. Inside the prepayment node app, the ExpressJS router pushes the request to the "request credit card" module or sub-app. (The prepayment node app also routes requests to the "request wire transfer" module, the "re-date orders" module, and the "view prepayments" module.) Each module or sub-app is basically its own web app.

I see the same kind of hierarchy being used for RESTful services.

What I still don't know is: (a) how a hierarchy of routes would impact performance, and (b) what kinds of pain points I'm creating for administration and maintenance. If this kind of hierarchical approach doesn't work, then I'm back to square one.

But I'm starting to think this question isn't just a node issue. Wouldn't I be facing the same problems with routing if I were using PHP or Java on the IBM i?

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: Wednesday, October 14, 2015 11:39 AM
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'm always open to other points of view.


There seems to be general agreement about external reverse-proxies / load-balancers being an effective means of "routing" work to multiple Node.js instances (Jobs), which ensures scalability and fail-over support.
There doesn't seem to be much distinction whether one uses IIS, NGiNX, Apache, or whatever for external request routing.

It would be nice to see some benchmarks pertaining to Node's internal load-balancing via the "Cluster" module. I'd be a bit wary of it after just reading the documentation.

The question that has me the most stumped is the one about "routing"
potentially thousands of URLs to appropriate JavaScript routines, with each routine pertaining to various "applications" within "modules" within "major-system-areas" (however you organize you broadly-scoped services)?

Kevin indicated that Node has to be restarted each time a routing configuration changes in Sails. Inline-coding of routes in Express obviously suffers from the same problem. I'd be concerned about performance as the number of URLs increase.
--
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.