Feature request: Configuration-driven proxy filtering

[bradygaster]

In most of the scenarios where I've used YARP, I've found it useful to copy in a class I borrowed from another sample created during the Project Tye era that would read in values from IConfiguration to be pumped into the route and cluster endpoint values. In an example by Shayne Boyer, which I've mimicked in the CustomConfigFilter class I created for the Build 2023 cloud native .NET demo code, a configuration-driven filter would give developers a conventional way of mapping environment variables to placeholders in their YARP configuration.

Take the appsettings.json code below, from the same Build 2023 demo repo:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "System.Net.Http.HttpClient": "Warning",
      "Yarp": "Warning"
    }
  },
  "ORDERS_API": "http://localhost:5004",
  "STORE_UI": "http://localhost:5176",
  "ReverseProxy": {
    "Clusters": {
      "Frontend": {
        "Destinations": {
          "Store": {
            "Address": "{{STORE_UI}}"
          }
        }
      },
      "OrdersApi": {
        "Destinations": {
          "Store": {
            "Address": "{{ORDERS_API}}"
          }
        }
      }
    },
    "Routes": {
      "ClientRoute": {
        "ClusterId": "Frontend",
        "Match": {
          "Path": "{**catch-all}"
        }
      },
      "OrdersApiRoute": {
        "ClusterId": "OrdersApi",
        "Match": {
          "Path": "/api/orders/{**catch-all}"
        },
        "Transforms": [
          { "PathPattern": "/api/orders/{**remainder}" },
          { "PathRemovePrefix": "/api" }
        ]
      }
    }
  }
}

In this code, the ORDERS_API and STORE_UI values are hard-coded in the file as settings, so they'll be read in from here by default or from environment variables. The placeholders {{ORDERS_API}} and {{STORE_UI}} are replaced with the values in these settings or environment variables at runtime, making it easy for developers to use environment variables to route traffic between services. It also gives developers who want to integrate things like Tye with YARP to create new service discovery approaches.

I'll follow this issue up with a pull request to add the filter to the product's code.

[Tratcher]

It seems like you're doing 1:1 mapping of route patterns to destinations without any of the other features like health checks, load balancing, etc. In that case the new MapForwarder API might be more appropriate.

app.MapForwarder("{**catch-all}", configuration["STORE_UI"]);
app.MapForwarder("/api/orders/{**catch-all}", configuration["ORDERS_API"]);

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "System.Net.Http.HttpClient": "Warning",
      "Yarp": "Warning"
    }
  },
  "ORDERS_API": "http://localhost:5004",
  "STORE_UI": "http://localhost:5176"
}

Are you actually using the transforms in that example? They seem misconfigured.

[samsp-msft]

This feels like it should be more part of Aspire and a bigger question of how to do API gateways in Aspire. TestShop and eshop both have instances of YARP that use the service discovery Aspire component.

This is probably better addressed with #2525 and having a Aspire apphost component for YARP.
Deploying a YARP to ACA to map URLs seems a bit redundant, but c'est la vie

[NapalmCodes]

I have a use for the docker image approach as well, but agree it is a bit redundant. I created an API gateway container component for Aspire but because service discovery awareness is an http client feature there is no good way to send traffic to multiple instances of an API (dynamically hardcoding is doable for each host but not ideal). YARP as a sidecar would enable the gateway to use service discovery indirectly as a "dumb" forwarder.

The other choice as I see it is emitting all the host values for each replica as an env var like services__apiservice__http__<index> instead of just the 0 indexed value as seems to be the case right now.