6 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 a
by 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 agoYARP 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.
- oaiey 5y agoI 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
- BeefWellington 5y ago> 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.
- 9wzYQbTYsAIc 5y ago> the terms of "best" insinuating "best for anyone" rather than "best for software developer at Microsoft" -- a key difference. As Ballmer used to say: “developers, developers, developers”. Microsoft has long known that what is best for developers is what is best for Microsoft.
- 9wzYQbTYsAIc 5y ago> Yes, when does this happen? In highly regulated or extremely sensitive industries.