Hacker News Reader

Comment by rafale | Hacker News Reader

How does this compare to nginx? Does it support websockets? I have an asp.net core websocket based app that need to support hundred of thousands concurrent websockets connection. I ll be taking a look at this because I don't wanna expose Kestrel directly to the internet.

View on HN

Used it several weeks ago at work in an app which actively uses WebSockets. It just works.

The main difference I see is that YARP is added right into the dotnet project itself. See the getting started :

https://microsoft.github.io/reverse-proxy/articles/getting-s...

From my understanding Kestrel passes request to this.

> The proxy server is implemented a plugin component for ASP.NET Core applications. ASP.NET Core servers like Kestrel provide the front end for the proxy by listening for http requests and then passing them to the proxy for paths that the proxy has registered.

I see. So it can operate in-process? Could in theory be much faster than nginx out-of-process model.

Why would someone need an in-process reverse proxy? I don't see what an in-process proxy would add that a request routing engine couldn't do. Or is the point that you can now add your reverse proxy configuration as just another project within the same solution?

And you could dynamically and efficiently add/remove web apps and endpoints assuming your entire codebase is in C#.

You can also block the clients for a brief period while you make routing changes, or wait for any other arbitrary event to complete. This is one way to achieve zero-downtime upgrades, even in situations where the service is running as a single binary on a single host.

We use it to proxy request from "modern" part of application moved to .net core to legacy parts of application, that are yet to be converted.

This is a "premiere use case" we've seen people use YARP for.

I was assuming more the latter. Also benefit is you can extend and customize in C#.

You might need to deploy a single executable rather than multiple.

I think it either operates as a traditional (heavily customizable) reverse proxy OR you have a app and forwards x% of your API surface to second tier services.

Imho: no in-procees reverse proxying. That should not make sense.

So, basically vendor lock-in is the difference?

Extensibility via C# for custom rules. It's not as attractive if you have nothing to customize but we've found lots of developers want to write code to influence the proxying. If you're a .NET developer or you don't like writing LUA (what nginx uses) then you can use YARP.

It supports WebSockets, HTTP/2 (including gRPC) and HTTP/3 (with .NET 6+).

Reply on news.ycombinator.com