22 ms·

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

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.

Macha 5y ago
> 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.
- chunk_it_away99 5y ago
  NGINX is also more portable. It runs on more architectures and operating systems than .NET/C#. I can literally throw a stick and hit several devices in my office that NGINX runs on but C# does not.
  - 9wzYQbTYsAIc 5y ago
    Does nginx have Tizen support?
- 9wzYQbTYsAIc 5y ago
  > Only the select() and poll() (1.15.9) connection processing methods are currently used, so high performance and scalability should not be expected. https://nginx.org/en/docs/windows.html https://nginx.org/en/docs/windows.html
BeefWellington 5y ago
> 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.
- oaiey 5y ago
  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.
  - BeefWellington 5y ago
    > 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.

Macha 5y ago

> 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.

chunk_it_away99 5y ago
NGINX is also more portable. It runs on more architectures and operating systems than .NET/C#. I can literally throw a stick and hit several devices in my office that NGINX runs on but C# does not.
- 9wzYQbTYsAIc 5y ago
  Does nginx have Tizen support?
9wzYQbTYsAIc 5y ago
> Only the select() and poll() (1.15.9) connection processing methods are currently used, so high performance and scalability should not be expected. https://nginx.org/en/docs/windows.html https://nginx.org/en/docs/windows.html

BeefWellington 5y ago

> 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.

oaiey 5y ago
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.
- BeefWellington 5y ago
  > 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.