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#.
Re:Microsoft YARP
by 9wzYQbTYsAIc on Sunday February 20, 2022 @10:06PM
(#30411521)
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.
Re:Microsoft YARP
by ComodoHacker on Monday February 21, 2022 @02:55AM
(#30413038)
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.
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.