No post body was provided.
Microsoft YARP
11–20 of 153 posts
Re: Microsoft YARP
#12Re: Microsoft YARP
#13Quoted post unavailable.
https://devblogs.microsoft.com/dotnet/announcing-yarp-1-0-re... https://aka.ms/aspnet/benchmarks (click on the "1 of 21" pagination at the bottom of the page and select "Proxies"). You can compare it to nginx, envoy, and haproxy.
So this thing is 2x faster than Envoy, something wrong in the benchmark probably.
Re: Microsoft YARP
#14Sometimes 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, Go and Java, there were generally benefits in various shapes and sizes like different security models, performance vs. capability trade-offs and integrated vs. specialised solutions. In this case, it just seems to be a "we don't want the stuff we didn't build ourselves" which is a shame considering the benefits of pooling resources on existing implementations would have.
Re: Microsoft YARP
#15Quoted post unavailable.
https://devblogs.microsoft.com/dotnet/announcing-yarp-1-0-re... https://aka.ms/aspnet/benchmarks (click on the "1 of 21" pagination at the bottom of the page and select "Proxies"). You can compare it to nginx, envoy, and haproxy.
I’m on mobile, and that page is very slow and very tiny. Anyone got a TL;DR?
Re: Microsoft YARP
#16I'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/ Direct Forwarding so I have more control over how things route:
https://microsoft.github.io/reverse-proxy/articles/direct-fo...
Re: Microsoft YARP
#17Sometimes 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,…
>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
Re: Microsoft YARP
#18Sometimes 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,…
> re-implementing something with no discernible benefit keeps eating time/resources all over the place.
> is a shame considering the benefits of pooling resources on existing implementations would have.
What exactly would you prefer these developers spend their time on instead of this work?
There are a lot of benefits to being able to integrate your own reverse proxy directly into your software stack. C# developers enjoy these as much as anyone else would.
Re: Microsoft YARP
#19Sometimes 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,…
It's only in the last 5 years that .NET was open sourced and made available officially for Linux systems. Up until then most C# use was strictly on Windows, and OSS especially for Windows server side stuff (IIS, SQL server, etc.) was (and still is) pretty rare. I've seen windows server places (Microsoft) implement everything from redis, memcached, queue systems, prometheus, lucene, DNS servers, to reverse proxies, etc. entirely from scratch out of necessity. Years and years of man hours going into building and supporting something that would be a simple debian package install on Linux.
I have no insight into it but my gut tells me windows server exclusive shops are probably dwindling and have long ago realized they needed to start moving to Linux, especially now that .NET is officially supported there. I think the days of reinventing everything in C#/.NET/windows are coming to an end fast.
Re: Microsoft YARP
#20Earlier quoted context omitted.
https://devblogs.microsoft.com/dotnet/announcing-yarp-1-0-re... https://aka.ms/aspnet/benchmarks (click on the "1 of 21" pagination at the bottom of the page and select "Proxies"). You can compare it to nginx, envoy, and haproxy.
I’m on mobile, and that page is very slow and very tiny. Anyone got a TL;DR?
50% slower than nginx and haproxy