"...narp?"
Microsoft YARP
51–60 of 153 posts
Re: Microsoft YARP
#52Sometimes 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,…
Seems like the fact that its built in C# isn't really the main point. The main point it that it runs on asp.net infrastructure
Re: Microsoft YARP
#53Earlier quoted context omitted.
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?
I was assuming more the latter. Also benefit is you can extend and customize in C#.
Re: Microsoft YARP
#54Earlier quoted context omitted.
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…
Can you share more specifics on what you needed to customize that went beyond nginx's capabilities?
This was 5+ years ago so I'm a little hazy on the details. A lot of it was just plugging into our infrastructure for config, service discovery, rate limiting, logging, etc.
- Logging the exact metrics we wanted to our metrics service. (We wrote a bunch of Lua code to do this.)
- Loading the set of backend services from Zookeeper. (We had a sidecar process that would periodically sync from Zookeeper to a config file, then call `nginx reload`.)
- Routing requests to different datacenters based on where the user's data was homed. (We had Go libraries to do this, and it would have been nice to be able to just call into that. I think we ended up putting this functionality in the sidecar.)
- Changing the way we streamed a response based on an HTTP header from the application. (We ended up writing a C module for this.)
- Changing the backend selection algorithm from "least connections" to "best of 3 random choices". Nginx added support for this in 2018, apparently.
There were ton of things we solved with Lua, which wasn't ideal. Since that's the only Lua in our codebase, everyone who touches it has to make a mental switch to remember all the weird edge cases (as you do with any language), plus 1-based array indexes, plus no static types.
Plus, any Lua or C you write has be contorted to fit Nginx's multi-stage request/response architecture. If you're writing a plugin that is meant to play nice with other plugins, then the contortions may be worth it. But for us, a proxy library would have given us the freedom to write code that was simpler and easier to understand.
The team moved to Envoy after I left: https://dropbox.tech/infrastructure/how-we-migrated-dropbox-...
Re: Microsoft YARP
#55Earlier quoted context omitted.
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?
And you could dynamically and efficiently add/remove web apps and endpoints assuming your entire codebase is in C#.
Re: Microsoft YARP
#56Earlier quoted context omitted.
> 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. I take this at face value but it would be nice to know what the benefits are vs nginx and other off the shelf solutions. The readme explains the benefit for Microsoft but not how it stacks against off the self solutions.
> it would be nice to know what the benefits are vs nginx and other off the shelf solutions. Biggest difference in my view is being able to make synchronous blocking calls directly into any arbitrary business code in order to determine the fate of a request. This can include rule/policy engines as well as auditing & tracing frameworks.
Lua in nginx can you get very far in my experience.
Re: Microsoft YARP
#57Earlier quoted context omitted.
> 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 performa…
You can find the Socket partial class files here:
https://github.com/dotnet/runtime/tree/main/src/libraries/Sy...
Socket.cs, Socket.Unix.cs, Socket.Windows.cs, etc...
AFAIK, there are no parts of libuv left in .NET Core. That was mostly used to quickly get the framework up and running on Linux.
Re: Microsoft YARP
#58"...narp?"
No luck caching them proxies then?
Re: Microsoft YARP
#59Sometimes 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.
The Go standard library?
Re: Microsoft YARP
#60Sometimes 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
And how would we cope with this in, say, 100 years, when the list of required functionalities is much larger, and a new language comes along?