Live data from Hacker News

Redbird: A modern reverse proxy for Node

github.com

11–20 of 77 posts

Re: Redbird: A modern reverse proxy for Node

#11
post #9
post #8

Earlier quoted context omitted.

"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 :-)

One reason could be that it might be easier for node.js devs to read and understand its source code. I don't use the software nor have read its source code, though.

Re: Redbird: A modern reverse proxy for Node

#13
post #9
post #8

Earlier quoted context omitted.

"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 :-)

Sometimes I think that there are not enough of real problems to solve in the js world.

Too many people pumped into a tight space of the frontend development are creating in there another copy of the whole infrastructure while limited by the tools that weren't designed for that.

Re: Redbird: A modern reverse proxy for Node

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

Re: Redbird: A modern reverse proxy for Node

#15
post #7
post #2

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.

https://github.com/webpack/webpack-dev-server Would this work? Or what’s the issue you are referring to?

I'm pretty sure he's aware of Webpack's devserver. A common problem is multiple libraries (with different webpack configs) being built that are required inside a single app. I guess GP's approach is to run multiple devservers, all on a different port, and then put a reverse proxy in front of it.

Last I checked, webpack does support building multiple scripts (by turning the `entry` config setting into an array or object), but they'll all have the same settings (so that intermediate results used by multiple entry points only need to be built once). If webpack since added support for multiple entire configurations behind a single webpack dev server then that would be splendid of course, but last I checked they didn't.

We have a similar problem at my company that we build our frontend React code for the browser and for node, and the latter has subtly different build settings. Our solution is to run the webpack devserver for the browser, a webpack watch mode for the nodejs version, and then we run the nodejs version using nodemon so that it reloads whenever the webpack watch mode rebuilds. The nodejs version contains an expressjs reverse proxy to forward requests for things in the `assets` directory to the webpack devserver. It's messy, but it works. My biggest beef is that it's rather dissimilar from our production setup.

Of course if we'd done node+browser from the start we'd have written our code such that the node version could be run in node without a compilation step, but we were first frontend-only and then added server rendering, and by then the code already made use of a number of webpack-isms (such as weird require("raw!css!stylus!myfile.styl") type of stuff).

Re: Redbird: A modern reverse proxy for Node

#16
post #9

Earlier quoted context omitted.

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 :-)

Sometimes I think that there are not enough of real problems to solve in the js world. Too many people pumped into a tight space of the frontend development are creating in there another copy of the whole infrastructure while limited by the tools that weren't designed for that.

Node was designed to build networking applications just like this.

Re: Redbird: A modern reverse proxy for Node

#17
post #6

I 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

how would npm install nginx be different from [yum|apt] install nginx?

Re: Redbird: A modern reverse proxy for Node

#19

Earlier quoted context omitted.

Sometimes I think that there are not enough of real problems to solve in the js world. Too many people pumped into a tight space of the frontend development are creating in there another copy of the whole infrastructure while limited by the tools that weren't designed for that.

Node was designed to build networking applications just like this.

No, node was the realization that JS’s concurrency model could be applied to applications like this.

Re: Redbird: A modern reverse proxy for Node

#20

Earlier quoted context omitted.

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

how would npm install nginx be different from [yum|apt] install nginx?

Its a local installation, inside the folder, instead on the operating system. Also, other people will automatically install it when the package is saves inside the package.json or yarn file. You can also limit the version you want with these files, that the end user dont need to think about. Just yarn install :)
Post reply on HN