Live data from Hacker News

Microsoft YARP

github.com

141–150 of 153 posts

Re: Microsoft YARP

#141
post #115

I am late to the party here. What is the purpose of a reverse proxy? Reading online: security, load balancing, https seems to be mentioned. It appears a bit to me that a reverse proxy is not doing what a web server used to do back in the days of IIS/Apache. I see a lot of programs meant to operate on the web that use very simple http servers.

I think of a reverse proxy as more of a general architectural pattern - when you have cross-cutting concerns for an application with a relatively broad protocol (HTTP) you can implement them as a networking layer in front of the service(s). Indirection and abstraction are powerful tools in computing. Common reasons for such a split: 1. Composing several different services into a single internet domain 2. Putting stat…

to add to your list:

8) avoid cross-origin problems and prevent unnecessary OPTIONS preflights that result in uneeded roundtrips by bundling mutiple FEs+BEs into a single origin with different paths (as opposed to mutliple domains/origins).

Re: Microsoft YARP

#142

>> We found a bunch of internal teams at Microsoft who were either building a reverse proxy for their service or had been asking about APIs and tech for building one I'm really curious, does Microsoft have a crew of anthropologists walking around to figure out which team is reinventing wheels?

> I'm really curious, does Microsoft have a crew of anthropologists Quite literally, yes. Microsoft research has (or at least had) anthropologists on crew.

That's actually cool! I feel it's great they do some introspective work, no matter the company size.

Re: Microsoft YARP

#143

Worth noting that YARP (or as someone has eloquently described it as PRAY) here was another Microsoft project which basically killed a previous open source project which did the same thing: https://github.com/proxykit/ProxyKit

We know there is an ongoing issue with MS's relationship with .NET OSS ecosystem, but in this case I am totally fine with this. I proved the need of a code-first, highly extensible/customisable reverse-proxy (vs other approaches with config only and/or scripting). I also discovered on my journey there where things that needed to happen in layers I couldn't control nor influence (e.g. HttpClient, Kestrel etc) that YARP team could get done. I expressed these things when I had a meet with the team.

Ultimately we got a solid product with a not-too-dissimilar API and I have one less thing to maintain :)

Re: Microsoft YARP

#144
post #90

Earlier quoted context omitted.

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

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

Re: Microsoft YARP

#145

YARP is yet a another example of how C# is becoming a dominant systems language. The ease with which you can build a tailor-made reverse proxy is pretty amazing.

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

Re: Microsoft YARP

#146

YARP is yet a another example of how C# is becoming a dominant systems language. The ease with which you can build a tailor-made reverse proxy is pretty amazing.

>C# is becoming a dominant systems language In 2022 everything is a system programming language. Next on that list is Javascript, I am sure.

>In 2022 everything is a system programming language. Next on that list is Javascript, I am sure.

Yes but cool people will write their systems software in Typescript. :)

Re: Microsoft YARP

#147
post #39

Earlier quoted context omitted.

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

Lua vs C# - chose your poison. There's a ton of AspNet Core libraries for handling http things e.g. JWT handling. Things that might need the licensed version of nginx.

Also it's embeddable and self-hostable into any .NET / AspNet Core application.

Re: Microsoft YARP

#148
post #144

Earlier quoted context omitted.

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

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…

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

Re: Microsoft YARP

#149
post #144

Earlier quoted context omitted.

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…

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

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

Re: Microsoft YARP

#150

YARP is yet a another example of how C# is becoming a dominant systems language. The ease with which you can build a tailor-made reverse proxy is pretty amazing.

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

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

https://github.com/MichalStrehovsky/zerosharp

Post reply on HN