81–90 of 153 posts
YARP is yet a another example of how C# is becoming a dominant systems language. The ease with which you can build a tailor-made reverse proxy is pretty amazing.
Perhaps a bit of a stretch. I am currently choose golang for a more systems like project because of startup time and gc pauses in c#/dotnet. Definitely nice to see nativeaot which should address the startup time issues.
Earlier quoted context omitted.
I guess I have to ask: What exactly is the use case for a tailor made reverse proxy? What customizations do people typically want to offload to the reverse proxy?
The main use case that comes to my mind is when you want to deploy a proxy in an environment where the developer needs full oversight of the proxy internals and doesn’t want to learn the particulars of configuring any given proxy software suite. Additionally, YARP is cross-platform capable, so you can run the same proxy on Linux, macOS, and Windows. NGINX doesn’t even provide that, for example. In terms of customizat…
Yes, when does this happen? That's what I'm trying to understand. You've provided some possible feature benefits to a DIY solution but you're really just trading NGINX internals for YARP internals here. At first glance, to my eye, one of those is going to have better community support and documentation.
> Additionally, YARP is cross-platform capable, so you can run the same proxy on Linux, macOS, and Windows. NGINX doesn’t even provide that, for example.
Yes it does? You might need to elaborate because this is just incorrect but I suspect you're trying to make a different point.
> In terms of customizations, YARP is more like “what feature do you need to build in” than “how do I need to configure”. You can quickly build a simple reverse proxy and just about as easily setup a full load balancing solution, but the simple use case doesn’t need to include any of the code for the advanced use case.
My main issue with this idea is that the average consumer of this is going to be better positioned to handle the engineering hurdles of writing their own advanced use cases.
I'm glad to see Microsoft supporting more low-level magic like this. I've written my own version of ReverseProxyMiddleware more times than I can recall... The most painful parts were always around translating between HttpClient and HttpContext. Looks like Microsoft abstracted this exact concern away under the IHttpForwarder and ForwarderHttpClientContext types. Looking at the docs around this, I'd probably start w/ D…
Earlier quoted context omitted.
>Sometimes it feels like Microsoft and/or C#-enjoyers just want to re-implement everything that already exists It sometimes feels to me, like a huge percentage of developers reinvent the wheel
There are thousands of Java accounting apps and thousands of shitty medical billing websites. I think most devs are definitely reinventing the wheel for the ten thousandth time
I had this exact experience: “why should I reinvent the wheel?” Oh this solution doesn’t let you apply partial payments or apply one payment to multiple invoices. This one doesn’t create account statements. This one can’t fax invoices. This one only supports Stripe (and has its own undocumented billing API because who would use anything other than Stripe?). This one has a weird XML definition system for subscription pricing which makes it difficult if not impossible to handle negotiated rates on a per-account basis. Not to mention having to teach billing people how to write the weird XML. This one won’t prorate invoices. This one is a cloud service that costs $100+ a month and is liable to be unavailable when I really need it! They all have weird features that I will never use.
Ok, we’ll go with this imperfect one and make some changes. But where’s the entry point? How does weird framework in weird language even work? What are the conventions? How is the original developer differing from those conventions?
And then you come to the realization that the wheel gets reinvented because the existing wheels were made with specific business logic in mind. While this can often be generalized for a particular industry or set of use cases, it often does not and can not cover all use cases. The wheel is reinvented.
(Not so fast with the XKCD comic about new standards. We’re not imposing standards on others, we just need our software to work for us.)
Sometimes the wheel doesn’t need to be reinvented. Some help desk software I wanted to use needed some slight tweaks. The entry points were obvious and the development environment was easy to setup. I made the tweaks and was good to go.
"YARP is a reverse proxy toolkit for building fast proxy servers in .NET using the infrastructure from ASP.NET and .NET."
Sometimes it feels like Microsoft and/or C#-enjoyers just want to re-implement everything that already exists. While having many implementations to choose from if you need to select a solution to an outstanding problem is great, it makes me wonder why re-implementing something with no discernible benefit keeps eating time/resources all over the place. In similar cases of implementing reverse proxies in C, C++, Rust,…
There aren't a lot of good proxy development frameworks. There are decent lower level libraries, and proxy servers with limited scriptability. I've spent the last 4 years at Fly.io wishing for a nice, full featured, proxy framework. This looks pretty darn good to me.
Only available in .NET ecosystem, got excited after I read the title, but forgot Microsoft is Microsoft. "YARP is a reverse proxy toolkit for building fast proxy servers in .NET using the infrastructure from ASP.NET and .NET."
YARP is yet a another example of how C# is becoming a dominant systems language. The ease with which you can build a tailor-made reverse proxy is pretty amazing.
> yet a another example of how C# is becoming a dominant systems language Perhaps a bit of a stretch. I am currently choose golang for a more systems like project because of startup time and gc pauses in c#/dotnet. Definitely nice to see nativeaot which should address the startup time issues.
Earlier quoted context omitted.
There aren't a lot of good proxy development frameworks. There are decent lower level libraries, and proxy servers with limited scriptability. I've spent the last 4 years at Fly.io wishing for a nice, full featured, proxy framework. This looks pretty darn good to me.
A Ruby on rails shop like fly.io would use .net?
(At any rate, they employ Chris McCord, the creator of Phoenix, and have spent considerable resources pushing Phoenix. So it's clear that they aren't beholden to any one language or ecosystem.)
Earlier quoted context omitted.
The main use case that comes to my mind is when you want to deploy a proxy in an environment where the developer needs full oversight of the proxy internals and doesn’t want to learn the particulars of configuring any given proxy software suite. Additionally, YARP is cross-platform capable, so you can run the same proxy on Linux, macOS, and Windows. NGINX doesn’t even provide that, for example. In terms of customizat…
> The main use case that comes to my mind is when you want to deploy a proxy in an environment where the developer needs full oversight of the proxy internals and doesn’t want to learn the particulars of configuring any given proxy software suite. Yes, when does this happen? That's what I'm trying to understand. You've provided some possible feature benefits to a DIY solution but you're really just trading NGINX inte…
So you are right, it is a very specialized situation, but the key stakeholders who asked, contributed and collaborated with the .NET group are exactly these engineers who previously did a DIY solution.