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 :-)
Redbird: A modern reverse proxy for Node
11–20 of 77 posts
Re: Redbird: A modern reverse proxy for Node
#12Automatic routing via Redis
Could anyone explain to me how does this work and what is automatic routing in this context?
Re: Redbird: A modern reverse proxy for Node
#13Earlier 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 :-)
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
#14Re: Redbird: A modern reverse proxy for Node
#15Was 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?
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
#16Earlier 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.
Re: Redbird: A modern reverse proxy for Node
#17I 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
Re: Redbird: A modern reverse proxy for Node
#18Re: Redbird: A modern reverse proxy for Node
#19Earlier 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.
Re: Redbird: A modern reverse proxy for Node
#20Earlier 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?