> 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.
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 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.
> 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 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.
YARP was not a self motivated product. Engineering groups within Microsoft asked the .NET group to help them with their custom (.NET) reverse proxies. And the .NET group added it to their portfolio.
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.
> YARP was not a self motivated product. Engineering groups within Microsoft asked the .NET group to help them with their custom (.NET) reverse proxies. And the .NET group added it to their portfolio.
This is an interesting take that I think is perhaps naive. Microsoft has a vested interest in pushing .NET as a development platform and can push teams to use the company's flagship programming stack in everything it does. From the perspective of given individual teams within the company this may not appear to be self-motivated but how could it not be, given the driving requirements to use MS-approved technology stacks?
What your comment misses the mark on is what the driving force behind those engineering decisions is. If the decision is driven by corporate guidance to use .NET or else (this is a hypothetical), it's not exactly because the engineers themselves wanted to write something from scratch in .NET to solve a particular well-solved problem.
I think they are quite pragmatic. For sure they will prefer a language which they trust and can influence (see here) for green field assets but that is just one of many considerations.
Office for example took React Native as a UI toolkit and invested in that instead of .NET. Typescript was invented to help them. The Windows division uses C++ based COM / WinRT and built a independent framework.
Microsoft is not a pure .NET shop. There are not even a anti-Java shop
> I think they are quite pragmatic. For sure they will prefer a language which they trust and can influence (see here) for green field assets but that is just one of many considerations.
While this is no doubt true the implied context of my reply was to the idea that Microsoft's engineers were selecting the best available option, the terms of "best" insinuating "best for anyone" rather than "best for software developer at Microsoft" -- a key difference.
> Office for example took React Native as a UI toolkit and invested in that instead of .NET.
Only after many years of trying to make WPF work and seeing the tide go another way.
> Microsoft is not a pure .NET shop. There are not even a anti-Java shop
For sure, C# and J# were basically the replacements for the failed attempted co-opting of Java that was J++. As far as I can tell their only Java related product is their own build of OpenJDK designed to be used on Azure. It's unclear what contributions they've really made in the space.
While they may not be a "pure .NET shop", I'd bet they're the closest thing out there.
I'm not suggesting Microsoft 100% ignores broader trends but this is sort of an aside from the crux of the original commentary.
> 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
nginx runs on all three of those platforms. If you mean the binary, this is surely misleading as you just move the burden from getting your platform specific binary to your platform specific .net runtime.
A common one are multi-tenant applications where you want to dynamically (depending on data in a database for example) route requests to different places (like docker containers).
The first specific example I can think of is JupyterHub - it handles user management and starting/stopping Jupyter Notebook servers, then provides a reverse proxy for users to access their notebook servers directly.
We have used this on a net core app when yarp was only a very basic half abandoned solution.
Basically, we needed to to auth on each request (can the user see this per a slightly complicated rights system) and we routed to automatically spin up containers,so discovery was also custom
We have one at work. This came from a distrust of developers’ abilities to correctly configure Apache and NGINX and a desire for the ability to roll out company wide changes that affect reverse proxying or headers we always want to set or remove on each request cycle.
That's interesting that the time spent developing your own solution was viewed as simpler and a better investment than using existing solutions out there (even commercial ones).
If you can speak to it, when it was rolled out were there numerous issues related to clients misbehaving? IME projects like this are "easy" to get out the door as it were, but usually wind up causing a load of support headaches due to massive implementation gaps.
>YARP is yet a another example of how C# is becoming a dominant systems language.
It won't become a systems language until it will let you to directly access hardware and do memory management, it will have improved performance and it will be natively AOT compiled.
It already is a systems language and has been since the outset. Managed code is the preference, but you can certainly run unmanaged code with direct memory access if you want to.
The ease with which you can build a tailor-made reverse proxy is pretty amazing.