YARP – Microsoft toolkit to build fast reverse proxy servers | Hacker News Reader

YARP – Microsoft toolkit to build fast reverse proxy servers

microsoft.github.io

143 pointsdgellow66 comments

Why do people chose names for tools or libraries starting with "Yet Another...". I know naming can be hard, but anything can be better.

Want a name, here are a few: Camel, Druid, Beetle, Quetzalcoatl, Omaha. You can even use a random website name generator, or character name generator to get names that don't mean anything but are readable.

yarp is much more googleable than "camel"

It’s geek ironic, but yeah the trend is kinda thick. It’ll be interesting to see how easy it is compared to other reserve proxies. I am def not a dev op guy but there’s a few things where it feels like I am learning another coding language just to do something that seems like it would be easy to document and get done sooner but, you end up needing a certificate to learn how to use an image buck for instance.

anywho

Not sure if you are being sarcastic, but Camel and Druid are already taken: Apache Camel & Apache Druid :)

I used them as examples.

Camel would imply it’s written in Perl.

In open source I assume anyone calling something “yet another X” is acknowledging that other X type programs exist, but don’t fit the needs or scratch the itch for the creator. You can take it or leave it.

I much prefer naming technologies with unique names, and acronyms are probably the best way of achieving that. It's much easier to discuss and google than using a common word.

Camel is an especially bad example, as there is already an Apache project by the same name, plus the Caml dialect of ML (of which OCaml is a much more popular descendant). Not to mention the animal, the brand of cigarettes, and the prog rock band...

CAMEL is also a protocol to let enhanced mobile services use SS7 interfaces as specified by 3GPP for Intelligent Networks (IN)

Eh, I prefer naming technologies with a mix of both a unique name and it's purpose, otherwise it all gets too crowded.

Personaly I find...

Camel = Bad

Camel Reverse Proxy = Better

But again it's personal taste

CaRP sounds a little fishy though.

Better than the Camel Reverse Auto Proxy!

I suspect in this case “yet another” was picked at least in part to make a cultural reference for humour value. Bung yarp into Google or similar and you'll get many images from Hot Fuzz.

Yet Another {Foo}

Libre{Foo}

It's an old tradition, dating back (at least) to yacc.

Especially if the name spelled backwards is “PRAY” ;).

I think you wanted to use the adjective reverse.

Remember that most of MS products have hyper descriptive and generic names.

Their SQL server is called SQL Server. Their MVC framework is called MVC.

Meanwhile their team messenger has changed names like 12 times.

And anything dev-y gets swallowed into the Azure brand.

YARP is a huge step up. If they'd followed their typical approach, this would be either "Reverse Proxy" or "Azure RequestFlows"

Yet I personally prefer both "Reverse Proxy" and "Azure RequestFlows" to YARP.

I guess it's personal taste.

Until you work with multiple platforms and you're trying to figure out if we're talking about Microsoft's reverse proxy, or and F5 somewhere, or maybe that Nginx.

Personnally I like it.

It implies they know that the space is already pretty crowded. Yet, they find there was place for yet another because they bring an angle or feature that is worthy of existing.

There's even a website for it - https://www.thisworddoesnotexist.com/

We use Azure AD Application Proxy because it's an approved technology/pattern. Sadly SAML auth doesn't work with MSAL 2.x frontends because auth tokens are clobbered - gh bug #3420 - so we're looking at replacing it.

Right now the USP of Azure AD Application Proxy is that it "just works", give or take a bit of powershell. Replicating the functionality behind their Azure edge network and proxy connector groups is costly. It would be helpful if this project dove-tailed with the Azure edge side so we could run our own proxy connectors.

An example of inner source becoming open source; YARP began as a way to unify multiple internal .NET reverse proxy projects. Once mature and used internally it was opened up to the rest of the world...

It is a nice idea (ASP.NET is a great platform), but it is not really ready for broad use.

I gave it a try, because I'm a .NET dev and nginx configuration always confuses me. There are a lot of things still missing from YARP:

  - Configuration/API still has some rough edges
  - For a lot of things (funky header stuff), you still need to write your own Middlewares
  - Missing documentation for a lot of features
  - No good Letsencrypt support
  - Caching and cache conrol is also very limited

I hope you left feedback!

- Writing code in a .net based language is one of the strengths.

- let’s encrypt isn’t built in but can be added by using https://github.com/natemcmaster/LettuceEncrypt

- Not sure about the caching one. Do you have more details?

Yes, the code first configuration in .NET attracted my interest. Also it's testability. I don't understand why they push their JSON configuration so much. If you want config files, take nginx, HAproxy, Traefik, ...

LettuceEncrypt is more or less currently unmaintained. Way too risky to use, no idea how to fix that, if something breaks.

About caching, this issue sums up my issue quite well: https://github.com/dotnet/aspnetcore/issues/27387

I went with Traefik after all, I'm quite happy with that choice.

Fair! Glad you found something that works.

Out of curiosity, Traefik has output caching ?

No it doesn’t. At least not the free version.

YARP got me interested, because I thought I could write some complex caching rules in C#. But you can’t, so every other proxy that doesn’t cache is as good as YARP ;)

Uh, not sure I understand. Do you mean you didn't want to write the logic? That issue you point to just means the component doesn't exist out of the box. Is that what you meant?

I wanted to implement some very specific caching rules, based on some POST parameters inside a JSON.

This seems to be possible with nginx and Lua, you extract a unique cache key from your request, and then nginx caching takes care of the rest. But in my case not out of the box or without the paid version.

So I hoped to fix that problem with YARP, but I would’ve needed to implement my own caching as a completely new middleware.

In the end I implemented the caching in the database.

Any comparisons and/or benchmarks with Traefik or NGINX?

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.

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

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.

Or Caddy?

I think this project is for when you need to do some fancy request modification that's hard/slow to do with Nginx or the like.

It's not meant to compete speed-wise with other off-the-shell reverse proxies.

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.

I've not examined this in detail, but it'll have to go some to beat Golang's stdlib for easily coding up a reverse proxy.

I've had to do it a few times now for special applications and each time the reverse proxy part was mere minutes of work compared to the application code.

No. Every golang stdlib proxy I've tried to use is a toy. They very inefficiently copy the message body and the memory behaviour is just horrible. Try posting a 10MB message. (That's actually not a lot for modern technology) and it will grind to a halt.

Would it possible to share your findings?

This is actually a great project. Makes it really easy to set up a reverse proxy for test purposes and control it programatically and has a lot of tweakability (adding stuff like latency is trivial). Surely the best of among alternatives for integration testing of .Net applications.

I bet that Hot Fuzz fans greatly approve of the name.

Playtime's over.

First thing I thought of reading this title was "Narp".

Not another reverse proxy

Absolutely. Was going to comment ‘…narp?’, until I saw your post.

Great, now dogfood it to the guys responsible for "netsh interface portproxy", easily the most unreliability "OS level" port proxying I've ever seen.

when they say reverse proxy server does it mean like nginx? so this tool is like create your own nginx instead of configuring and existing reverse proxy server like nginx?

The way I've understood it, it's more closer to the latter

Yes, with configure-via-code being an option.

I wonder how this handles TLS. I have tried using dot-net's HttpListener object but was a little disappointed in how it handled TLS.

(In the end, I used HttpListener in localhost-only mode and had an off-the-shelf proxy service to deal with TLS.)

YARP can be used on IIS, Http.Sys (HttpListener), or Kestrel, and each handle TLS setup differently. If you didn't like the HttpListener model you should try Kestrel instead, it's all configured in process (or appsettings.json). https://docs.microsoft.comaspnet/core/fundamentals/servers/k...

Recognizing that YARP's goal is to be, well, a reverse proxy, I'm none the less hopefully that a Toolkit-like ecosystem that is currently missing with the stagnacy of Ocelot pops up around YARP.

this is like spring cloud gateway? looks pretty cool

Well good for them for not picking name used by any opensource this time.

Reply on news.ycombinator.com