1. What happens when the reverse proxy goes down ...
Let me apologize up front for turning the question back on you. Beginning
with the "reliability" concern - which is more likely to go down - a server
which is performing "proxy" services? or one which is running "application"
code?
And how complex are the "applications", and how often do they have errors?
Regarding going down for maintenance, wouldn't the same rationale apply for
Node HTTP services? How often will a Node.js HTTP service go down in order
to apply a change to an application?
2. What happens when I ... want to add or modify a single reverse proxy
route...
The HTTP service must be restarted, which can be disruptive. To ameliorate
the disruption, one option is to have a reverse proxy configured on 2
boxes. Use a network "router" to point HTTP traffic to the other HTTP proxy
while the primary one is restarted, and visa versa.
3. What about all of those port numbers?
As Aaron pointed out, the network will not have a problem with that. The
question is whether it adds work to an administrator's job to keep track of
which services are on which port? Again, the same concern for doing
"routing" within Node.js.
Some good questions and answers have been shared in this discussion. I
would like to reiterate Kevin's question - what is a good definition of an
app?
Back to the reliability concern. For a long time, I have maintained a rule;
DON'T mix HTTP services and Application services in the same "process". For
that matter, I recommend NOT mixing any kind of "socket" communications
with "application logic" in the same JOB.
That "rule" is NOT a mainstream practice, so I'm relegated to the status of
going against the grain. But I believe it has paid off - big time! Socket
communications should not be "disrupted" by application errors.
midrange.com
