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.
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...
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.
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.
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 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.
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.
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
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.
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.
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.
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.
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.
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?
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 sort of like stopping when reading some tutorial on nginx and the example app the tutorial is using to show how nginx works is written in php because you're too cool for that php stuff.
The difference with Microsoft is that even if their product fails, you're still going to get support for years and years. Like, Silverlight was deprecated in 2012, and apparently it stopped being supported a month ago. That is why a lot of the enterprise folks like their products.
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.