YARP VS service-fabric

➡️ Release 2.0.0-RC.1 · microsoft/reverse-proxy · GitHub ➡️ Visual Studio 2022 17.5 Preview 3 is here!

In your application, you may be using YARP, to build a reverse proxy gateway sitting in front of various backend applications. For example, you may run YARP to listen on example.org, and have it proxy all requests going to this domain while mapping /api and /docs to different web apps running on diffreent servers.

Microsoft's YARP is exactly this.

If I were optimizing for broad community adoption, I would have written this in Go or Rust. However, I really enjoy writing in C# and I can practice Go and Rust at work. For this reason I decided to go with .NET Core C# and used YARP.

The website has this to say:

One thing I'd like to add as a potential differentiator as well is that YARP runs very well on Windows and because it's build on ASP.NET Core, can run inside of IIS and directly on HTTP.sys as well (which means we can take advantage of cool features like http.sys request delegation where possible https://github.com/microsoft/reverse-proxy/commit/b9c13dbde9...). This means you get platform portability AND deep platform integration for free.

The first on the list is the entry project .sfproj. They use a non-SDK-style project template with a bunch of .xml files for configuration but with no C# code. They require Fabric.MSBuild nuget to build and package Service Fabric apps. Unfortunately, the dotnet add package command won't update dependencies since they only support and non-SDK-style project template uses the package.config file to manage dependencies.

Considerable amount of Azure Service Fabric is written in C# https://github.com/microsoft/service-fabric. As many people mentioned already, until .NET Core, no platform developers really cared about C#. Perhaps in future we may see interesting things happen with a lot of performance optimisations coming to C# as well.