Allow providing dynamic routing callback

[mkosieradzki]

It would be great, if I could provide a callback that will make decision where to route request. Without this I need to fork entire middleware (because my routing rules change during runtime).

If that's acceptable I would be happy to make a pull request.

[Tratcher]

Note we're not actively developing or shipping this component. We know the configuration and routing need quite a bit of design, but don't expect to do so any time soon. I'd recommend creating your own fork to experiment with for now.

[mkosieradzki]

I've actually copied code from this component long time ago and it is extremely useful. I would like to put some effort into it based on my experiences with proxying for Service Fabric, but it only makes sense if I it will receive a fighting chance to be integrated :).

IMO This component is really not so far away from being production ready.

[mkosieradzki]

@Tratcher Quick question: Can I make ProxyOptions immutable? (It would be part of larger refactoring). Or is there some non-optional convention requiring public setters on properties on middleware options classes.

[Tratcher]

I don't follow, what's the point of Options that you can't change?

[mkosieradzki]

@Tratcher You configure all options using constructor and construct object that is immutable. It's cleaner because no one can modify options when middleware pipeline is actually running (what can have unpredictable effects and is far from recommendations), and also allows to create some options constructor overloads for different scenarios.

[Tratcher]

Ah. We do that for most classes, (e.g. middleware), but not for Options. Not all of the settings may be known at creation, you create the Options and then keep configuring it until you're ready. See this pattern:
https://github.com/aspnet/BasicMiddleware/blob/dev/samples/ResponseCompressionSample/Startup.cs#L23

[mkosieradzki]

I like this pattern with lambda as well it limits the scope where you can modify options. OK. I will have some looks on pre-existing middlewares, but I will definitely refactor the current implementation as I don't like it.

I am sorry to take your time (but this discussion will save a lot of it during code-review ;) ).

Would it be acceptable if I make ProxyOptions class private implementation detail and provide some convenient overloads for RunProxy

For example:
RunProxy(option1, option2, option3 = 80)
RunProxy(option1, option4)

And if complex configuration is needed (I don't expect it yet):
RunProxy(options => {
options.RegisterRoute(...);
options.RegisterRoute(...)
})

[Tratcher]

Having RunProxy overloads for common options is fine, but keep them simple.