Reverse proxy

[jordan-breton]

I created a reverse proxy using uWebSockets.js that forward any HTTP traffic to the desired HTTP server.

It allows getting uWebSocekts.js performances for your websockets while using whatever HTTP server behind (express, koa, nestjs, ...) on the same port.

It comes at a cost as it adds a (tiny) overhead to your HTTP requests, but you would have needed a proxy to deliver your app through port 443 anyway.

For scenarios where you need to improve websockets performances while having to maintain/enhance an app relying on well-established frameworks, it really helps to quickly move forward. And if you just want to use your favorite framework and all its plugins/extensions/packages without having to rewrite them yourself, uws-reverse-proxy may be a solution that suits your needs :)

GitHub: https://github.com/jordan-breton/uws-reverse-proxy
NPM: https://www.npmjs.com/package/uws-reverse-proxy

Examples: https://github.com/jordan-breton/uws-reverse-proxy-examples

[uNetworkingAB]

The problem with projects like these (and there are tons of them) is that people generally believe performance is an additive, as in, they believe that as long as I somehow shoe-horn this "fast brand" into my project, regardless of how - it will magically apply the traits of "fast brand" onto whatever product one is building.

We saw this very clearly in 2016 where people shoe-horned uWS into Socket.IO and saw no significant improvement, but went around believing they had fixed all problems in the world with a click of a button. So the message got consumed & ignored and people continued making the same old shit they had made before.

In reality, performance is a subtractive, as in - the lowest common denominator makes up your end performance. If you still encourage people to mix uWS with Express - you are encouraging people to build products with dreadful performance.

It is way better, to let people build something good from the ground up, than to persuade them into making something half-assed because they cannot take the time to invest some basic amount of time & attention into something that performs way better.

[jordan-breton]

I got your point, and I agree with you 100% that for a new project, you shouldn't* start with crappy bases (I don't even use express, fastify nor NestJs myself).

But that's not the whole story.

Depending on my mission either as a freelance or as a consultant, I had to work with many projects that had really bad foundations using very bad frameworks (and very poorly, to add up). Most of the time, my clients just can't afford a rewrite from scratch. In those cases, changes must be incremental. Because technical performances is not the only metric we have to take into consideration in such a case. They are economic, skill and time constraints too. It's all about tradeoffs.

So, yes, when the application is evolving in a way that intensifies websockets usage, it's a good move to use the kind of proxy I created to just be able to move forward by, at least, resolving app instabilities. They must start somewhere, at some point. They can't just pause everything telling their users, "Sorry, our product has been built on a giant pile of crap. Wait a few weeks/months/years and we'll be back with a major release that will do better 😅"

They can planify that release, but before releasing it they must also resolve the immediate problems they have while continuing to maintain their product.

A proxy like this is obviously not suitable as a long-term solution and, yes, some people will use it as a long-term solution because no matter how many warning and explanation we write everywhere people will misuse what we create. They need time to learn, or maybe they don't care. But this is a point I will try to make more explicit in the documentation of my package.

That being said, thanks for your reply and, while I'm sure you're reading: thanks for your work. This project is amazing and saved some of my client's life more than once :)

[*] Performances is not the only metric when we have to choose what package to use or not when we start a project. Sometimes, the number of plugins offered in a sub-ecosystem like express allows you to go way faster on the market with your product (trading for technical debt, without a doubt). The early stage of the project is important not only to set up future conditions for success in the long run, but also to be able to just bring the project to life. Without any revenues, some projects can't afford to exist in the first place. In those cases, a bad implementation going to production is better than a perfect start aborted before getting released because of running out of time or money.

I would like to see a day where the equivalent of the express ecosystem (in terms of features, not architecture, of course) is available for uWebSockets.js, but I fear that we must wait a bit before it comes up. In the meantime, it just cost too much time and efforts to reimplement the whole thing from scratch in a new project. A proxy, in another hand, is a welcomed crutch until a project can afford a better architecture/design.

[e3dio]

If you spent as much time converting your Express app into uWS.js as you did writing your multi page essay response you would be done by now, it is easy to do. Then you would have real performance rather than going thru 2 different http servers which is much worse than 1

[uNetworkingAB]

Or, at worst, used any of the Express-like uWS wrappers. Then you would at least be halfways there.

[jordan-breton]

@e3dio have you ever worked on real projects written for real purposes by someone else before coming here to answer me with that much arrogance? I did answer with a very polite tone to engage in a discussion, not to argue nor to be unpleasant. I would expect you to do the same.

And, now, when an application uses multer, passport, and a ton of other express middlewares whose properties/features are plaguing the entire codebase in every direction, and when node:http response/request objects are spread across the entire codebase, replacing it by uWebSockets.js is neither as trivial nor as fast as you assume it to be. Especially when those objects are spread all over the place. It depends on the size of the project, too.

Sometimes, a client doesn't even want to replace express because it’s what he and his team only knows about, or because he wants to be able to just yarn add whatever express package will be available in the future in no time and use it without having to reimplement it himself or pay someone to do it, or because he just want to work on actual features for his users instead of spending times, money and efforts to reinvent something that is working fine enough for his usecase.

And, yes, when someone take the time to talk to me, I take the time to write a proper answer. If reading a long message is something that incomodate you, feels free to ignore it.

[uNetworkingAB]

Sounds like you are shoe-horning uWS in under an otherwise rotten app.

Instead of lifting a heap of rot onto uWS and calling it a day, you could take 1 route or 1 service and move it fully over to uWS. Then you take another route or service and gradually port it over.

From what you describe it sounds very unlikely you'll see any improvement at all, right now, except piling on even more layers of complexity.

Sounds like fixing legacy code by piling on what soon will be even more legacy code