Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft YARP

github.com

Post reply on HN
Print view View original

41–50 of 153 posts

Re: Microsoft YARP

#41

Post by zamalek »

cakoose wrote: post #24
oneplane wrote: post #14

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,…

To clarify, are you saying that: 1. There are already good reverse proxy libraries in C#? 2. There are already good reverse proxy libraries in other languages? 3. There are already good reverse proxy applications ? If it's #1, then yeah, it would be nice if the ReadMe explained why YARP is different. To be fair, they're at least consolidating a bunch of efforts within Microsoft: > We found a bunch of internal teams a…

> But over time we needed to customize things in ways that were difficult to do within Nginx's architecture (either in Lua or in C),

Yup. Eventually a configuration language becomes a shitty programming language, so why don't we just use a programming language?

Re: Microsoft YARP

#42

Post by akshayshah »

moogly wrote: post #37
akshayshah wrote: post #28

Earlier quoted context omitted.

mdasen has already pointed out that "2x" seems to overstate the difference by quite a bit. YARP also has a spikier max latency, which I'd expect for a GC'ed language. I don't see a way to choose the benchmarking platform in the PowerBI dashboard, so I assume all these numbers were collected on Windows. In that case, it doesn't surprise me that YARP is faster: Envoy uses libevent for cross-platform I/O, but libevent i…

> Kestrel, YARP's underlying webserver, uses libuv instead Kestrel (as used in ASP.NET) uses a Socket-based transport since .NET Core 2.1 The libuv transport was marked as obsolete in .NET 5 and has been removed as of .NET 6, I believe.

Ah, good to know! I'm barely C#-literate, so the Socket docs[0] aren't totally intelligible to me. Somewhere under the hood, though, there must be a common abstraction sitting in front of the relevant Windows and Linux syscalls - did the libuv stuff just move down a few layers, or is this using something completely different?

Either way, I'd be shocked if this weren't designed top-to-bottom to have excellent performance on Windows.

[0]: https://docs.microsoft.com/en-us/dotnet/api/system.net.socke...

Re: Microsoft YARP

#43

Post by AlphaSite »

oneplane wrote: post #14

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,…

It competes with this: https://spring.io/projects/spring-cloud-gateway AFAICT.

Re: Microsoft YARP

#44

Post by mrkurt »

oneplane wrote: post #14

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.

Re: Microsoft YARP

#48

Post by tremon »

rafale wrote: post #40
politelemon wrote: post #36

Earlier quoted context omitted.

The main difference I see is that YARP is added right into the dotnet project itself. See the getting started : https://microsoft.github.io/reverse-proxy/articles/getting-s... From my understanding Kestrel passes request to this. > The proxy server is implemented a plugin component for ASP.NET Core applications. ASP.NET Core servers like Kestrel provide the front end for the proxy by listening for http requests and t…

I see. So it can operate in-process? Could in theory be much faster than nginx out-of-process model.

Why would someone need an in-process reverse proxy? I don't see what an in-process proxy would add that a request routing engine couldn't do. Or is the point that you can now add your reverse proxy configuration as just another project within the same solution?

Re: Microsoft YARP

#49

Post by throwuxiytayq »

pydry wrote: post #32
assttoasstmgr wrote: post #31

Earlier quoted context omitted.

Would your reaction have been different if, instead of Microsoft, this article was submitted by some random person entitled "Show HN: I built a reverse proxy in C#"? By your logic, the world should be operating on a single OS, with a single web browser, paired with a single web server, because why re-implement something that already exists?

Pretty much every "I built a thing" post is met with the same response. MS isnt special. I think pretty much every open source project that wants to be taken seriously needs to compare itself with its competitors.

Given that pretty much all of the recent Microsoft's open-source projects under the .NET umbrella, including ASP.NET Core, have been a resounding success in terms of communiry adoption, I don't think they're very shy about comparisons.

I expect some of the comments under this post to age very badly.

Re: Microsoft YARP

#50

Post by Shadonototra »

anything that requires a giant runtime to run is a big NO for me

that's why languages like GO makes more sense for that kind of use cases

microsoft not wanting to support CoreRT back in the days was their biggest mistake ever, shame on the people at microsoft who lobbied against it, shame!

Post reply on HN