Sharing DestinationConfig objects between clusters with InMemoryConfigProvider -- safe?

[j3parker]

Consider a scenario where we have two routes, each with a different cluster, and each cluster has their own equivalent destination:

{
 "ReverseProxy": {
   "Routes": {
     "route1" : {
       "ClusterId": "cluster1",
       "Match": {
         "Path": "{**catch-all}",
         "Hosts": ["a.com"]
       }
     },
     "route2" : {
       "ClusterId": "cluster2",
       "Match": {
         "Path": "{**catch-all}",
         "Hosts": ["b.com"]
       }
     },
   },
   "Clusters": {
     "cluster1": {
       "Destinations": {
         "destination1": {
           "Address": "https://example.com/"
         }
       }
     },
     "cluster2": {
       "Destinations": {
         "destination1": {
           "Address": "https://example.com/"
         }
       }
     }
   }
}

Using InMemoryConfigProvider a faithful way to do this as code would be

services.AddReverseProxy().LoadFromMemory(
  ImmutableArray.Create<RouteConfig>(
    new() {
      RouteId = "route1",
      Match = ...,
      ClusterId = "cluster1"
    },
    new() {
      RouteId = "route2",
      Match = ...,
      ClusterId = "cluster2"
    }
  ),
  ImmutableArray.Create<ClusterConfig>(
    new() {
      ClusterId = "cluster1",
      Destinations = new Dictionary<string, DestinationConfig>() {
        { "destination1", new() { Address = "https://example.com" } }
      }
    },
    new() {
      ClusterId = "cluster2",
      Destinations = new Dictionary<string, DestinationConfig>() {
        { "destination1", new() { Address = "https://example.com" } }
      }
    },
  )
);

but InMemoryConfigProvider also makes this possible:

var sharedDestination = new DestinationConfig() { Address = "https://example.com" } };

services.AddReverseProxy().LoadFromMemory(
  ImmutableArray.Create<RouteConfig>(
    new() {
      RouteId = "route1",
      Match = ...,
      ClusterId = "cluster1"
    },
    new() {
      RouteId = "route2",
      Match = ...,
      ClusterId = "cluster2"
    }
  ),
  ImmutableArray.Create<ClusterConfig>(
    new() {
      ClusterId = "cluster1",
      Destinations = new Dictionary<string, DestinationConfig>() {
        { "destination1", sharedDestination }
      }
    },
    new() {
      ClusterId = "cluster2",
      Destinations = new Dictionary<string, DestinationConfig>() {
        { "destination1", sharedDestination }
      }
    },
  )
);

It looks like today YARP does not care or notice if you do this -- the two work out equivalently, e.g. there will be separate DestinationModel and DestinationState objects that just happen to share the underlying (immutable) DestinationConfig objects. Behaviour appears to be unchanged, e.g. destination resolution would still happen per-cluste, etc.

This is good/fine behaviour for us. We want to re-use destinations across clusters as part of our sharding strategies. However I am wondering if the maintainers would consider this a misuse of the APIs. If so we would just instantiate extra DestinationConfig objects (one per cluster that uses a destination.)

[Tratcher]

DestinationConfig is read-only input, it doesn't matter if you re-use it. It's actually designed to be re-used when reloading configuration after some inputs changed. I would only caution you not to re-use the destination names, those are consumed elsewhere in the stack like for session affinity.

[j3parker]

Ah I see that in session affinity, interesting. Thanks!