No. Usually web application would be exposed through FastCGI or similar
protocol.
Insisting that either your tiny web application that can do next to nothing is
the thing that owns 80/tcp (and/or 443/tcp) or runs behind a HTTP proxy is
stupid. Proxying HTTP requests properly is harder than it sounds, which is
surprising every now and then and thus is easy to screw up (what happens to
Host: header? who is the TCP client? is it HTTP or HTTPs?), and your tiny
web application, as I've called it, is not the only thing I want to host on
the machine.
Practically every company I've worked with uses an HTTP reverse proxy. When you use something like nginx, it's really not hard at all to get right. Support for HTTP is more widespread than support for FastCGI these days, especially with more obscure tech stacks.
Edit: You can run multiple apps on separate ports, so that shouldn't be an issue.
> It's not a matter of nginx. It's a matter of what assumptions are hardcoded in the application.
You haven't actually given any good examples for what makes HTTP reverse proxying bad. Things like dealing with the Host header are two-minute fixes that you only have to deal with once, but they really shouldn't even be issues in the first place. HTTP is well supported, well understood, easy to implement, and easy to scale. On the flip side, you might waste a lot of time trying to get your tech stack working with FastCGI if there isn't already existing support, and you don't benefit from any HTTP support you already have.
> Such a deployment looks terrible at best.
Again, "looks terrible" is not a valid argument against it.
> You haven't actually given any good examples for what makes HTTP reverse proxying bad.
Try running anything that generates absolute URLs in its HTML. And then try to
make it running under two different domains, for example. A clear cookie/URL
disaster, and it's all for web protocols from 2002, without talking about HSTS
or CORS yet.
> Things like dealing with the Host header are two-minute fixes that you only have to deal with once,
For every f&ckin' application.
> but they really shouldn't even be issues in the first place.
They shouldn't be, I agree, in that sense that it should be impossible to get
it wrong. With HTTP you don't have this and you need to deploy workarounds.
> On the flip side, you might waste a lot of time trying to get your tech stack working with FastCGI if there isn't already existing support,
Node.js may be the only offender here (I didn't bother to check). Virtually
everything else that is used for web applications supports FastCGI.
> and you don't benefit from any HTTP support you already have.
Like what? What exactly is the benefit of running HTTP between frontend HTTP
server and application's backend? Because the trouble with passing information
about the request is a clear downside.
>> Such a deployment looks terrible at best.
> Again, "looks terrible" is not a valid argument against it.
Oh, quite the contrary. Inelegant systems or deployments usually give a death
by a thousand cuts. Too many exceptions and rules and guesses to work with
them.
Just as we can judge the elegance of source code, we can judge the elegance of
deployments.
> What exactly is the benefit of running HTTP between frontend HTTP server and application's backend?
For some applications (those that fit within the constraints of REST - and, no, that's not all Web "apps") - you can sometimes get easy caching by dropping something like varnish somewhere between the user and the app.
> I only met FastCGI in PHP. All NodeJS apps I saw used HTTP.
And I met FastCGI in Python, Perl, Ruby, and Erlang (though I haven't used the
last one yet). Oh, and uWSGI can expose anything it runs through FastCGI.
My personal opinion is that web crowd (most of JavaScript programmers fall in
here) just doesn't want to learn from anybody else.
> Is there any benefit of doing it that way?
Compared to running the tiny web application on 80/tcp? Sure: I can run more
than one and I don't need root privileges for the application.
Compared to running the application behind a reverse proxy? Ditto: it's
virtually impossible to get the setup wrong, so it's easier in the long run.
