Redbird: A modern reverse proxy for Node
github.com
Redbird: A modern reverse proxy for Node
1–10 of 77 posts
Re: Redbird: A modern reverse proxy for Node
#2Was 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.
Re: Redbird: A modern reverse proxy for Node
#3[deleted]
Re: Redbird: A modern reverse proxy for Node
#4What 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?
Re: Redbird: A modern reverse proxy for Node
#5What 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?
I use PM2. It's very good, and it keeps things in the node ecosystem.
Re: Redbird: A modern reverse proxy for Node
#6I think the readme is missing a "why not" section. For example: why not use nginx instead, which more people have experience with.
Re: Redbird: A modern reverse proxy for Node
#7Was 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.
https://github.com/webpack/webpack-dev-server
Would this work? Or what’s the issue you are referring to?
Re: Redbird: A modern reverse proxy for Node
#8I think the readme is missing a "why not" section. For example: why not use nginx instead, which more people have experience with.
"Because they can" is often the most fitting answer. Even a tiny feature is worthy to start a totally new project with a fancy name.
Re: Redbird: A modern reverse proxy for Node
#9I think the readme is missing a "why not" section. For example: why not use nginx instead, which more people have experience with.
"Because they can" is often the most fitting answer. Even a tiny feature is worthy to start a totally new project with a fancy name.
To be precise, I meant "why not use ..." comparison. I don't mind why the project was started. Whatever the reason, well done for getting it to this stage! But the other side - why should we be interested - is interesting :-)
Re: Redbird: A modern reverse proxy for Node
#10I think the readme is missing a "why not" section. For example: why not use nginx instead, which more people have experience with.
Convenience is one
I've used redbird to create a local dev proxy that can run be via npm scripts (which were already in the repo) so our engineering team didn't have to run the entire constellation of docker containers if they were only working on frontend code, and the only setup required was `npm install` which they already needed to do
I do wish you could just `npm install nginx` though