Support CF Route Services

[fitzoh]

I started writing this up as a post on the spring-cloud Gitter, but thought it might make more sense to post somewhere a little more permanent.
I recently wrote a blog post about using spring cloud gateway to create a route service. First off/selfishly, I was wondering if anyone had suggestions on alternate approaches I could/should have taken to implement the route service.

Secondly, I wanted to bring up a couple ergonomic issues and see if they would make sense to create separate issues/contributions for:

• Should it be possible to create a route without a URI? This might make sense if the final destination is determined within a filter
• Does a single arg header filter make sense? This would just check for the existence of a header... instead of header("X-My-Header", ".*"), it would be header("X-My-Header")
• in GatewayFilterSpec:
  • Should add and filter both exist? It feels a little weird that they both exist w/ the same functionality
  • If add and filter are meant to be aliases, should it be possible to specify an order using add?
  • Should there be a varargs version of addAll? Adding multiple filters is currently a little awkward
  • Would it make sense to automatically get the order for filters which implement Ordered?

[spencergibb]

Header existence check added here 9d04c4e
GatewayFilter spec tightened here ee55ef5

I believe ordering is taken advantage of https://github.com/spring-cloud/spring-cloud-gateway/blob/master/spring-cloud-gateway-core/src/main/java/org/springframework/cloud/gateway/handler/FilteringWebHandler.java#L83
If not log a separate issue.

So the issue remains about URI. (nice blog post BTW).

I'd propose that we build in support for this. You are not the first to ask, and folks liked your post.

Make RouteServiceForwardingFilter a global filter similar to the ribbon one. Make the uri something similar to, like cf:route. RouteServiceForwardingFilter would only filter if the URI matched. I'd assume all routes would want to match the 3 headers, we could make a specific predicate for those.

Thoughts?

[fitzoh]

Cool, thanks for the quick updates, and I put in #192 for ordering.

I think Adding in a RouteServiceForwardingFilter is reasonable, it's fairly specialized, but it's not like there's a whole lot of overhead involved.

I feel like the dynamic routing might have use cases beyond just the cf route service, would dynamic:route maybe make sense (or .dynamicUri())?

edit: dyamicUri() probably wouldn't work too well for yaml config, I'm too used to using the code builders

[spencergibb]

I think dynamic is too generic since the filter is getting the URL from a cf specific header X-CF-Forwarded-Url. If we make the header configurable, then maybe something else.

[fitzoh]

So with a global filter to manage the forwarded URL, a route might look something like this?

return builder.routes()
        .route(r ->
                r.predicate(cfRouteServicePredicate)
                        .filters(f -> f.requestRateLimiter(args))
                        .uri("cf:myroutename"))
        .build();

[spencergibb]

yup, or even r.cfRouteServicePredicate()...

[scheuchzer]

Great! We also use the gateway as CF route service. So I can drop my workaround sooner or later. Thanks

[making]

I've sent a PR so that we can change the url dynamically.
Does adding more specific CloudFoundryRouteServiceFowardGatewayFilterFactory make sense?