Allow grouping and inheriting route config

[Tratcher]

The config model can get very redundant if you need to define the same property with the same value on many routes. E.g. the Host, BackendId, Metadata, auth, etc..

It may be possible to allow a config structure where routes can be grouped together and inherit some properties (backendid, Prority, metadata, auth, Host, etc.).

[samsp-msft]

Do you have an example? What will be different between the routes? Is it just the path to match? In which case would having AND / OR functionality in the paths enable a single route to match a wider set of URIs?

[Tratcher]

The example given in #134 was Host. If you have 20 routes with different paths but all with the same Host then it would be convenient to group those together so you only have to define the Host once.

• Group
  • Host: example.com
    • Route1: /foo -> Backend1
    • Route2: /bar -> Backend2
      ...

would having AND / OR functionality in the paths enable a single route to match a wider set of URIs?

You mean something like Route: /foo OR /bar? Routing already allows a parameter matching syntax like /{paramter}/baz that I'd expect to handle many of these cases.

[Tratcher]

Another request: #122 (comment)

Have a shared authorization policy for a group of routes.

[Tratcher]

IProxyConfigFilter has proven to be a useful approach to this problem, letting people provide a basic config and to programmatically fill in bulk data.
https://github.com/microsoft/reverse-proxy/blob/ddae8bf0438d5b431845eff82700e145f756175f/testassets/ReverseProxy.Config/CustomConfigFilter.cs#L14

[Tratcher]

Alternate proposal for the json based config: If someone defines a route/cluster named "defaults" this would not be rendered into its own route/cluster instance, it would be used to fill in default values for other routes/clusters.

• Pros:
  • You can enable a setting in one place and have it apply to all routes/clusters
  • You can still override the default per route/cluster
• Cons:
  • This is top level, it's not as granular as the grouping proposals discussed above
  • This wouldn't support any value templating or conditionals like you can do with IProxyConfigFilter
• Unknowns:
  • Would this convention need to be introduced before 1.0? Adding it afterward might cause conflicts for anyone that was already using those names for actual routes/clusters.
  • Would this also make sense for the code model? Why wouldn't you do it yourself when generating the routes/clusters?

[samsp-msft]

This reminds me of CSS or Styles in XAML - it seems great to have these kinds of inheritance rules, until you have to figure out what the resulting matrix looks like. These properties define the security rules for your site, and so it needs to be clear what will actually get applied - we don't have good route diagnostics and debugging today (I thought we had a work item for that but can't find it), until we have that I think we should hold off any features here.