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



Kelly,

It's nice to see questions which are relevant to the deployment of broadly
scoped systems. And I agree that the answer always seems to come back to
"routing".

I'm not sure how to answer your questions about options 1 - 3, so I'll ask
more questions which might provoke thought.

What would be the best tool for handling:

1. Request logging?
2. Response logging?
3. Gzip compression?
4. TLS encryption?
5. Serving static content?

One benchmark I came across showed IIS performing 2.5 times faster than
Node.js while serving static content, presumably due to caching. Apache
offers similar caching. Wait for a Node.js caching module? Build one
yourself?

Node.js experts seem to advise the avoidance of any computationally
intensive work within the main event loop. Would "computationally
intensive" include the evaluation of "routing" expressions?






On Tue, Oct 13, 2015 at 12:32 PM, 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



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.