We did some internally and while YARP-based reverse proxies aren't bad, they are not as fast as nginx or HAProxy and not as useful as nginx or HAProxy. It seems to be mostly for NIH-teams.
I think that is also what the documentation describes; it was made for internal teams that were already on the DIY track anyway and the intent is to make it a .NET-nail (for when all you have is a .NET hammer).
The downsides are (to me) somewhat obvious, there is no mindshare, no automation and no decades of experience. That can also be an upside since looking for documentation or examples will not result in old-outdated stuff since it hasn't been available that long.
These proxies are within reach performance wise. One of the reasons we did YARP was to push the performance boundaries of asp.net core and http client. It will also replace many of the front ends that were built in house (not many want to write lua or c to modify the routing logic).
The downside of yet another anything is that unless it is an order of magnitude better than what already exists is that it will split the available human resources. Not only that, it also isolates the users to within their own language/framework, promoting a monoculture (now there's a pun that could be made here).
While it's better than other in-house alternatives, it's not better for the entire ecosystem as a whole. The need for hyperlocal reverse proxies is a problem on its own, generally only solved this way due to organisational dysfunction or a very niche requirement.
Maybe? Turns out nginx, traefik and others came out after nginx and have gained some mindshare. Of course YARP has the "Microsoft" problem but I think the programmability is actually huge non-niche benefit (at least in what we've seen in practice)
This is probably true if you're putting a reverse proxy in front of a traditional three-tier monolith, but a programmable proxy is often useful. Sure, you can extend lots of proxies in C or Lua, but most application development groups don't hire for expertise in those languages (and may not have adequate library support in those languages).
If you're a .NET shop, it seems very useful to have a reasonably fast toolkit for deploying specialized proxies. It's still early days, but I'd expect this to become as fast as anything written in Go or on the JVM, which seems sufficient for many use cases.
Yep, I've been on teams where asking for approval to run your own proxy was out of the question, but "adding an extra module to the pipeline" was practically a rubber-stamp approval.
We're doing that with Envoy and OpenResty and both are (at this stage) faster and more flexible. We use Lua in both cases, so I suppose it becomes a .NET vs. Lua thing. But to me, when your infrastructure becomes a language/framework fight we're in the wrong battle anyway.
>> But to me, when your infrastructure becomes a language/framework fight we're in the wrong battle anyway.
It is to me as well, but these fights are quite pervasive in our industry. It is especially problematic in the enterprise space. This is to the point as a C# dev, that I'm happy this exists, so that I have the facilities it provides, when more mature solutions are unavailable.
I can imagine a case where even some 'brand name box' proxy/balancer or rolling your own are the only choices available. In such a case, YARP wins instantly (at least from my perspective).
If I can't inspect what critical elements in my request pipeline are doing I don't want them. This even applies when we get Big-IP/F5 buying nginx and putting that inside the name-brand boxes, it's still too opaque to be useful for me.
I'd be surprised if they are trying to compete with these. This is targeted at a different audience. Often this is part of a .NET application migration where a company is comfortable with Microsoft-originated open source, but still uncomfortable with regular open source (even though we are aware of the pedigree of nginx.)
Going further, it can be customized from .NET and shipped as part of the app which may be using nginx for some proxy features.
