Hacker News Reader

Comment by oneplane | Hacker News Reader

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.

View on HN

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).

It’s new, give it some time

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.

> for when all you have is a .NET hammer

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.

Reply on news.ycombinator.com