Accessing currently configured routes/HttpClient from other services

[pinkfloydx33]

Is there a way to access the current list of routes along with their respective HTTP clients/transformer/forwarder?

We are using YARP primarily as an API gateway. We would like to build a component that is able to aggregate the OpenApi specifications of the downstream services and display them in a single SwaggerUI (hosted within the YARP application).

I imagine having a background hosted service responsible for this that would iterate the currently configured routes and search for some piece of identifying Metadata (since we are proxying other things). It would then using the associated HTTP client to request the OpenApI document from a well-known endpoint on the downstreams.

Is there some way to access this information? If so, would the associated HTTP client be available as well or would I need to manage those seperately? The downstreams require some headers we add as transforms, so ideally I'd just be able to reuse the existing transforms associated with the route and not have to manually track those, acting almost as-if I were an external request.

I realize I'd also have to react to configuration changes (I think there's an interface for that?) but taking baby steps on this for now. Is something like this possible?

For reference, I got the idea from a library dedicated to aggregating the OpenApI specs of an Ocelot gateway: https://github.com/Burgyn/MMLib.SwaggerForOcelot

[Tratcher]

No, not right now. There's a proposal to make that data available as part of another feature.
#126 (comment)

The HttpClient would be available. The transforms wouldn't work well for locally composed requests, they assume content is copied from an HttpContext.

Reacting to config changes is only one problem. Another is how do you detect that the destination service has been updated and you need to re-compute the Swagger doc?

[pinkfloydx33]

Yeah I rethought some of it and wouldn't need the transforms, just the client...

As far as detection of downstream changes, I figured I'd periodically poll the downstream to grab the latest doc which wouldn't be that bad a thing. Obviously there'd be overhead for computing a combined specification, but in our case we expose an internal "version" endpoint, so I could poll that for changes and only grab the new spec when it differed.

Either way, I'm sure I could come up with something if I had access to the route data.

[Tratcher]

Short term you could resolve the IProxyConfigProvider to get the raw config input and use that.