yarp should we use it, dynamic route creation at runtime

[christopherpross]

Hi,
I have a request and I hope you can help me. I have been trying for a few weeks to use Yarp for our purposes, but I keep running into limits.
We want to write an application that is a mixture of gateway and proxy. That means that requests have to be handled differently depending on the type. So far everything is clear, but I am implementing the simplest use case, a simple dynamic routing. The basic functionality is very easy to release via the Yarp config, but we want to have a separate config for this routing. The routing is a simple header based routing, but the config needs to be as simple as possible, as this will be maintained by people who are not programmers. For example, a single JSON file, with the simplest structure you can come up with. Also of course we want to use IOptions, keyword testing and different configproviders. I emphasize here that this is the simplest use case. My attempts so far have focused on dynamically changing and adding cluster-config, router-config or destinations at runtime. But all this is not possible because the properties are read-only. I'm trying to do this in a middleware, at software startup would be too early and I wouldn't know how to achieve this either.
I know that there is the possibility, with the "DirectProxieng", however there are also static routes that yarp should handle if possible quite ordinary and defined in the yarp-config, with all the features of yarp.
Also I have already read about the ConfigProviders, I understand that this can only be read at startup. In the future we will also have use cases where we modify existing headers and many other things in different variations.

I hope you understand what I mean, is yarp the right framework for this? Should we wait until certain features are implemented? What are your thoughts on this?

[Tratcher]

If you want to load routes from your own custom config format then we recommend implementing a IProxyConfigProvider provider:
https://microsoft.github.io/reverse-proxy/articles/config-providers.html

These support making changes at runtime via IChangeToken's.
https://microsoft.github.io/reverse-proxy/articles/config-providers.html#reload

[christopherpross]

@Tratcher Thank you for the quick answer. Yeah, I know about the ConfigProviders, the problem is, we need severial of them, each of them handles a specific type of request, this means I have to make the injection configurable. Maybe the following makes some clearer:

1. the request is recieved by yarp
2. it is given in a custom middleware
3. custom middleware identifies request on some parameters and gives the request to the next specialized ProxyHandler, a little class which wants to make modifications on the HttpContext. The logic should be contained in this handler, each handler has his own logic.
4. the result is given back and now given back to yarp.

That would be the best scenario for us, the manipulation on the context always includes the change of the destination, because we don't know at startup where the request gos to.

[Tratcher]

Ok, if your routing is truly dynamic per request then you need to use the direct proxying model.

You can use both models together as long as you make sure the defined routes don't overlap. E.g. define specific routes for the static routes, and then a catch-all route for the dynamic routes.