-
Notifications
You must be signed in to change notification settings - Fork 863
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
Extending configuration nodes with additional data #87
Comments
As this is a "Discussion" item that usually indicates we don't have specific action to take here yet. Should we plan to have a more concrete discussion on this and create some actionable work or are we not quite there yet? |
We actually already have something for this. Backend, BackendEndpoint, and ProxyRoute all have Read-only external config input should be stored separately from mutable runtime state due to concurrency issues. i.e. we shouldn't try to re-use this collection for the other two data types. |
I would like to see reverse-proxy/src/ReverseProxy.Core/Service/DynamicEndpoints/RuntimeRouteBuilder.cs Lines 51 to 54 in 4520fb1
|
I would like to add |
Hmm, I can see why you'd want those, but those aren't objects you'll be able to load directly from a config source. It would take some intermediate translation in the endpoint builder. We should be adding first class support for authz (filed #122). (And CORS?) |
I'm definitely in favor of adding first class support for authz (and CORS), but still I would like to see a
I'm thinking of using YARP as a backend for multiple SPAs and each needs different CORS settings. |
I think part of what @Tratcher was asking is how would you want to retrieve the objects. HttpContext has a feature collection, which is essentially an IDictionary<System.Type, object>, so items can be retrieved based on the key rather than having to search through a list each time. |
no I don't want to add these items to each request of |
Oh, I see. Endpoint.Metadata is a custom collection with generic search functionality (via downcasting). Ok, let me back up. Yes we need some way to add custom endpoint metadata. ProxyRoute is too low level for that, it's a raw config representation, you're not going to be able to represent complex objects like IAuthorizeData there. We likely need an event in RuntimeRouteBuilder that lets you customize the routes as we build them. You'd take some config metadata and translate it to complex objects like IAuthorizeData. reverse-proxy/src/ReverseProxy.Core/Service/DynamicEndpoints/RuntimeRouteBuilder.cs Lines 51 to 66 in ea7164c
|
Or maybe an event in DynamicConfigBuilder when we build the ParsedRoute object.
|
I'm adding some config events earlier in the pipeline but I think they're still too low level for this. |
Can we have first class support for CORS the way we have for authz? |
Can you open a new issue for that and outline what CORS support you're looking for? I'm not as familiar with that part of the stack. What would you normally configure per route? |
FYI I've split out the endpoint metadata event from #87 (comment) to #286, it's independent of the original issue here around various data stores. |
Triage: 1.0 has metadata, while not pretty, it is adequate. We can keep iterating on it post 1.0. |
Triage: Merge it into #1709 |
Duplicate of #1709 |
In looking at the round robin implementation and the features / scenarios @Kahbazi mentioned, we are going to need to be able to stuff extra information into these nodes.
There are a couple of scenarios:
Data that internal components will want to store, and will always be needed - these should probably go as properties directly on the objects
Data that some optional components will want to store, such as load balancing counters - For these I would suggest we go with something like the Feature collection from HttpContext. The key complication here is that it needs to be thread safe as it can be accessed from many workers simultaneously. This mechanism could also be used for custom components for storing state that does not need to be set by configuration. A further complication is whether this state is persisted across configuration changes - I would suggest it should be, with some form of notification so that the owning component can decide what to do.
Data that needs/can be specified by the user as part of configuration. For example if a load balancing scheme is to direct a percentage of traffic to particular nodes, that needs to be specifiable. I think it may be better to implement a dictionary approach for specifying properties on these nodes so that we have flexibility to add what is needed.
I am trying to think of YARP as a framework for a proxy with extensibility as a core tenet - we aren't going to cover every scenario with built in components, so we need to be consider how extra components are going to hook in and store their state.
The text was updated successfully, but these errors were encountered: