[rshm]

Still without ssl. Nice to see lots of stars and forks.

[nilved]

SSL is really not the responsibility of the web framework.

[bigdubs]

There are deployments where the traffic from the LB => app instances needs to be encrypted, so it would be the requirement of the server.

Source; I build secure financial services software day to day.

[k__]

Are reverse proxies always the way to go?

[stefs]

i always just use nginx and don't see any downsides.

[tracker1]

In the age of "microservices" it seems to be the direction. Also, in any HA deployment, would generally be the case anyway.

[dozzie]

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.

[RussianCow]

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.

[dozzie]

> Practically every company I've worked with uses an HTTP reverse proxy.

Well, there are people who can say the same about Node.js or RoR. Not that it makes a majority.

> When you use something like nginx, it's really not hard at all to get right.

It's not a matter of nginx. It's a matter of what assumptions are hardcoded in the application.

> Edit: You can run multiple apps on separate ports, so that shouldn't be an issue.

Of course it is an issue. Such a deployment looks terrible at best.

[RussianCow]

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

[k__]

Interesting.

I only met FastCGI in PHP. All NodeJS apps I saw used HTTP.

Is there any benefit of doing it that way?

How does it work with WebSockets?

[dozzie]

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

> How does it work with WebSockets?

No idea. I don't develop web applications.

[krzyk]

> My personal opinion is that web crowd (most of JavaScript programmers fall in here) just doesn't want to learn from anybody else.

Where would you put Java programmers? I haven't seen FastCGI there.

> No idea. I don't develop web applications. So why do you talk about FastCGI? It is strictly for web stuff.

[k__]

I just read that WebSockets aren't supported by FastCGI, so I guess this is the reason for all the reverse proxying in Node-land, hehe

[IshKebab]

It includes a web server.