YARP - Yet Another Reverse Proxy
Today, I want to share a story about a .NET tool that I used for the first time, and that solved a real-world problem for me.
You’ll be going to learn about using a reverse proxy. You probably know what that is and use it regularly, or you’re like me and have heard of it but have never used it yourself.
As a contractor, I am currently implementing a product from scratch. While most of the development work is fun, at some point, you have to deploy and install the application to production for the first time.
In this project, everything changed from being a fun project to a challenge.
YARP - Yet Another Reverse Proxy
Before we learn how I used YARP, let’s take a step back and look at what it is.
​YARP is a reverse proxy that comes as a NuGet package for .NET applications. That means it’s not a compiled and ready-to-go reverse proxy, such as Nginx or Apache.
Instead, it’s a library we can integrate into an ASP.NET Core web application and build our own reverse proxy or application gateway app.
What Does a Reverse Proxy Do?
Let’s get another step back and learn about reverse proxies in general.
A reverse proxy is a web application running on a port on a server. Usually, it runs on port 443, the default HTTPS port.
It then acts as a proxy and forwards requests to different applications based on URL structure, subdomains, or other distinguishable features of web requests.
Why would you want to use that?
With a reverse proxy, you can run multiple services on the same machine and expose them all using the default HTTPS port 443.
Without a reverse proxy, you would have to use different ports because a port can only be occupied by a single application.
What about My Story with YARP?
Now that we understand a reverse proxy and why you might want to use it, let’s continue with the story.
For my project, I have to run two services on the same machine. I preferred a simple setup that runs both services on a dedicated port.
However, the IT infrastructure team and their firewall configuration are a mess. It took day after day, and traffic was still not appropriately routed.
Ultimately, I decided to introduce a reverse proxy and only use the default port on my virtual machine for incoming traffic.
It turns out that it’s a much more complex architecture to set up for me as a software provider, but it is simpler to make it work on their infrastructure.
In the end, I created a custom application gateway with an ASP.NET Core Empty project template and implemented YARP.
The configuration allowed me to terminate SSL on the reverse proxy and run the two services using HTTP on localhost on a dedicated port.
With this setup, the two services are not directly reachable from outside the machine, but the reverse proxy can route incoming traffic to the correct application based on the subdomain to make them available to the clients.
Another upside is that updating the SSL certificate is done in a single location without restarting the services. All I need to do is update the certificate and restart the reverse proxy.
I’m a developer and not an operations guy. I learned a lot going through the process, and if I knew everything I know today about firewalls and their IT infrastructure team, I’d probably go down the reverse proxy route from day one.
PREMIUM CONTENT
