Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow grouping and inheriting route config #164

Open
Tratcher opened this issue May 14, 2020 · 7 comments
Open

Allow grouping and inheriting route config #164

Tratcher opened this issue May 14, 2020 · 7 comments
Labels
Type: Idea This issue is a high-level idea for discussion.
Milestone

Comments

@Tratcher
Copy link
Member

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.).

@Tratcher Tratcher added the Type: Idea This issue is a high-level idea for discussion. label May 14, 2020
@samsp-msft
Copy link
Contributor

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
Copy link
Member Author

Tratcher commented May 19, 2020

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
Copy link
Member Author

Another request: #122 (comment)

Have a shared authorization policy for a group of routes.

@Tratcher
Copy link
Member Author

IProxyConfigFilter has proven to be a useful approach to this problem, letting people provide a basic config and to programmatically fill in bulk data.

public class CustomConfigFilter : IProxyConfigFilter

@Tratcher
Copy link
Member Author

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
Copy link
Contributor

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.

@Tratcher
Copy link
Member Author

Another request for adding a transform to all routes: #1928

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Idea This issue is a high-level idea for discussion.
Projects
None yet
Development

No branches or pull requests

2 participants