Hacker News Reader

Comment by KeitIG | Hacker News Reader

I am one of those JS guys who like to put JS/Node.js everywhere, but I do not get the problem Redbird is trying to solve: the Express.js doc is quite clear that for serious things, you should use a dedicated http server. [1]

If you just want reverse-proxying, you can choose between the simplicity of Caddy or the power of Nginx (or Apache). Why would I want to run a JS app (that I know will be less performant) to do that?

  [1] https://expressjs.com/en/advanced/best-practice-performance.html

View on HN

> If you just want reverse-proxying, you can choose between the simplicity of Caddy or the power of Nginx (or Apache). Why would I want to run a JS app (that I know will be less performant) to do that?

The same reason you'd use Caddy over Nginx or Apache, why use the former over the the latter when the latter already exist and are faster? Because someone who knows Go but not C can customize its codebase, just like someone who knows JS but not C or Go can modify Redbird's.

If Node.js is good enough to build and run servers then it's good enough to build reverse proxies.

I have used apache since version 1.0 came out. I have never needed to modify the code.

If you use this logic, you would not be able to run Linux because it is written in C, correct?

No, not correct. Why do you think it's okay to immediately jump to an absurd conclusion?

There's value in being able to modify the software you're using. That doesn't mean you throw out absolutely everything every single time you want to appreciate that value.

There are cases when performance is not your main focus but simplicity of use is. Like during development. I'd of course never use this in production, but it's perfect for my development needs.

I agree with the sentiment, but using nginx as a proxy is reasonably easy (at least after you make one that works and can reuse that configuration.)

The advantage of developing on as similar a platform to the projected production platform is that when you do deploy to a real environment, there are fewer nasty surprises.

It is not reasonably easy, I can't set it up completely with "git clone" and it does not stay inside the project (that's an issue when your developers use a huge variety of operating systems with varying installed and configured software). That means a lot of time lost during problem solving with the hundreds of developers I work with, most of them have never even heard about nginx, they're developers, not sysadmins.

There absolutely should not be any nasty surprises with switching a reverse proxy, and you can cover that with end to end tests. Such issue would be a bug in the reverse proxy.

Of course there are things like Docker, but that implies performance issues on Mac.

How easy is it to use nginx for dynamic proxying? Wondering, because the need I have is to be able to dynamically route requests to ephemeral flask apps that could be on a different host/port at any given moment. Not my design BTW, but it's what I need to do.

The thought was to have node manage the flask processes and another tracker service which would dynamically proxy to the apps. Can nginx provide this? Forgive my ignorance, just new to the concept of dynamic proxying.

nginx is just a web server so it doesn't have dynamic programming capabilities. However, if you wanted to do something like that from nginx you could script it in Lua using OpenResty https://github.com/openresty/

I don't have the numbers to back this up, but I would be inclined to believe that a Node.js implemented reverse-proxy would outperform Apache.

- node (whose main reason for existing is event driven IO) is in the same order of magnitude as nginx (whose main reason for existing is also event driven IO). I think sometimes people think node is ruby/python/php levels of performance. It isn't.

- And as another comment mentions, developer productivity may be better than minor performance difference - you mentioned Caddy, same rationale applies here.

- nginx is also a bit crippled as useful features (like dynamic reconfig) are only in the proprietary nginx plus.

- This has good defaults - having to set up the seperate webserver for ACME is a pain, this is way easier.

Do you know of a performance benchmark that shows the current status? I can't find many that describe node not at those levels of performance, Especially against Ruby.

Sure: https://iwf1.com/apache-vs-nginx-vs-node-js-and-what-it-mean...

I haven't seen anyone compare Ruby to node perf, unless there's a non blocking variant of Ruby (looks like nio4r), in which case it would have similar perf.

Likewise node vs Python Tornado would be a good comparison.

Thing is, nio4r and Tornado aren't the standard library. Whereas node's stdlib is: node's file and socket read operations etc are non blocking, Python and Ruby equivs are not.

Also (addressing weird moderation - sudden downvotes when I mentioned other languages): please don't turn this into a lang tribal thing: I personally think Python is a better language than JavaScript, it just blocks by default. This isn't a matter of preference, it's a fact.

That resource looks like node is faster than those other languages? I think you might be getting the down votes because your comment is being interpreted that it is slower.

Python: we use the node event loop too now (https://magic.io/blog/uvloop-blazing-fast-python-networking/).

But actually, you could have setup a pure Python server instead of nginx for the last 10 years with twisted.

Not that you should not consider uring nginx anyway: it deals with caching, load balancing, has great tutorials, it's battle tested, and has tons of pluging.

But performance wise, WSGI is not Python.

Sure, I mentioned Tornado a few minutes before you posted this. Twisted obviously counts too, I dislike the non-PEP8 coding style it uses but that's off topic. I love Python's non blocking features, they're just not in the mainline VM right now. Here's hoping for a libuv or whatever else non blocking Python 4 VM / stdlib.

Asyncio has been in the the mainline VM for quite some time.

Yep, the stdlib just needs to use it. In nodeland blocking is the exception: that's not yet the case in Python.

> I think sometimes people think node is ruby/python/php levels of performance. It isn't.

Except, it is ruby/python/php slow: https://www.techempower.com/benchmarks/#section=data-r17&hw=...

All of PHP, Ruby, and Python beat Node.js in the above-linked benchmark.

Raw number crunching performance is similar with Node and Go. Python and ruby are in different league than them. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Do you think this discussion or the OP is about "[r]aw number crunching performance" ?

Reply on news.ycombinator.com