from Hacker News

Redbird: A modern reverse proxy for Node

by Immortalin on 11/5/18, 3:05 AM with 74 comments

  • by KeitIG on 11/5/18, 10:09 AM

    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

  • by viraptor on 11/5/18, 6:43 AM

    I think the readme is missing a "why not" section. For example: why not use nginx instead, which more people have experience with.

  • by dzek69 on 11/5/18, 9:32 AM

    I used to use Redbird, but configuration is a bit weird and not very well described if you need to use Auto HTTPS feature. Project seems rather dead and bugs are solved very slow (upgrading to newer node version caused it to not install because of outdated dependency, iirc PR with solution were ready, but not merged for weeks (?)).

    Finally I got rid of it and replaced it with Caddy webserver

  • by uptime on 11/5/18, 1:25 PM

    I’m a fan of traefik. https://traefik.io

    I’m not ready for full k8s, but traefik gives me ACME and detects my docker containers and routes them for me.

    If I only need https redir I’ll use that or nginx.

    I can Redbird being useful where you only have node as an option.

  • by davnicwil on 11/5/18, 3:30 PM

    I mostly agree with the sentiment in other comments of just using nginx, but there is one standout feature here that looks incredibly useful:

    > We have now support for automatic generation of SSL certificates using LetsEncrypt. Zero config setup for your TLS protected services that just works.

    I've scripted this kind of letsencrypt certs automation before with certbot and nginx, which is fine but a 'just works' declarative plugin for nginx would be much nicer.

    Does anything like this exist? Anyone have experience with using it? Asking here as googling brings up a bunch of outdated forum threads etc to wade through.

  • by sbmthakur on 11/5/18, 7:13 AM

    From the roadmap section:

    Automatic routing via Redis

    Could anyone explain to me how does this work and what is automatic routing in this context?

  • by jaimehrubiks on 11/5/18, 6:29 AM

    What are some good practices to install this as a service (to replace apache, for example). Do you just setup a systemd script or you have any common utility for this? I read about pm2 being a common choice. Do you recommend it? Is there any alternative for multiple app types apart from node?

  • by skrebbel on 11/5/18, 7:41 AM

    This looks excellent. Is it intended to be integrated with other Node libs? I.e. can I use it as an express middleware somehow, or is it explicitly intended as a standalone thing - more like Nginx-but-configured-with-JS-instead-of-a-weird-custom-language? I can see value in the latter too, but I'm curious about the motivation here.

  • by Aeolun on 11/5/18, 11:43 AM

    0.2.3 released 4 years ago.

    I don’t know, a last release that long ago doesn’t inspire faith in the health of the project.

  • by rdsubhas on 11/5/18, 4:35 PM

    Quite nice. node-http-proxy is awesome, lacks a few features (but has a few more such as websockets). Redbird has http2 as well.

    But to be frank, we have used node-http-proxy and other stuff before. It doesn't end with development. People put this to reverse proxy API calls in production, and then the other stuff that this calls into - it also uses proxying to call more stuff. In general, if you find yourself using this as a "convenient, declarative way to route" in production, you _might potentially_ be digging yourself a hole. The lines between "harmless reverse proxying" and "service routing and discovery" can become thin.

  • by stonewhite on 11/5/18, 8:06 AM

    This would be more useful for my team if it would also transpile into nginx configuration.

  • by gigel82 on 11/5/18, 9:17 PM

    I'm surprised no one mentioned the threading situation in the comments. The main reason why you need a reverse proxy (like nginx) on top of your express app is because node.js is single-threaded. Yes, you can fork (which means a new process and IPC), but that's even more of a performance hog.

    If you have to serve a large static file - guess what... no other request gets processed at the same time. It's a neat idea but until we get true multi-threading in Node.js, I'll stick with my nginx, thank you very much.

  • by shard972 on 11/5/18, 5:48 AM

    Was recently looking for a reverse proxy for a project at work that utilizes multiple webpack repos that eventually gets built into one big webapp.

    Without a proxy your forced to only work on one area of the app at once so hopefully something like this will let me run all webpack instances under the same endpoint during dev.

  • by blorenz on 11/5/18, 1:44 PM

    I like the simplicity of this but am weary of using it in production based on other commenters. I would find something like this very useful if it would generate nginx configs instead of trying to function as the reverse proxy.

  • by novaleaf on 11/5/18, 4:45 PM

    Regarding proxies, could anyone recommend where to learn about implementing a proxy / proxy chain? a book, or online resource, etc.

  • by d--b on 11/5/18, 12:04 PM

    Sorry, but what’s a reverse proxy?

  • by erikpukinskis on 11/5/18, 11:43 PM

    What does “modern” mean in this context? ES6?

  • by api on 11/5/18, 4:49 PM

    This makes a very nice letsencrypt proxy.

  • by johnpython on 11/5/18, 12:14 PM

    Yet another JavaScript project reinventing the wheel and badly at that. It seems the NodeJS community suffers from NIH syndrome more than others. This is a sign of lack of seniors and leadership.