spring-cloud / spring-cloud-gateway Goto Github PK

First at all that project seems really promising, far better then Zuul 1 version!

Last day I was talking with @dsyer about designing/prototyping a kind of layout service / ui composition service (whatever the name) inspired from Zalando Tailor project (from global Mosaic project - Microservices for the Frontend).

Goal of such service is to avoid getting a well designed and decoupled backend service used by a big monster monolith (SPA?) frontend. Each microservices could be responsible on their own frontend/ui fragments, layout service / ui composition service will be only responsible to aggregate every fragments using a base/master template and returns it.

I wanted to develop by myself a kind of closely inspired fork to Zalando Tailor but using Java + Spring 5 + Spring Boot 2.0 + Reactor. Though I really need such piece of service on my current stack, at start that project was also a good candidate for training myself to Spring 5 + Spring Boot 2.0 + Reactor.

When I spoke that to @dsyer I also proposed an possible architecture based on Zalando one

And mine (Yes is a totally a clone of Zalando one )(Attention is a prototype, any box is not necessary a dedicated services. Is more a logical view)

At this point, @dsyer ask me why I have separated gateway and layout service. I don't really have a clear answer but in my mind, only reasons was separation of concerns and resilience (if layout service get down, you can continue using API). But I didn't think more.

That why I open you an issue (is more a discussion, I'm not asking feature request) to

1. Have your feedback to such service in microservices/cloud architecture
2. Your point about integrating it inside gateway or should be a dedicated services

Existing alternative or similar project to Zalando Tailor

• https://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919/ (BigPipe from Facebook)
• https://github.com/opentable/oc
• https://github.com/acesinc/convergent-ui
• https://github.com/lsm/micromono#doc_render_page
• (Play Framework) https://www.youtube.com/watch?v=4b1XLka0UIw

Here some sources of inspirations about Microservices for Frontend topic:

• https://www.mosaic9.org/
• http://scs-architecture.org/
• https://www.youtube.com/watch?v=vCzTK4XPfX8
• https://www.youtube.com/watch?v=jJxmi8nrHwg&index=83&list=PLe1TplHMknuLAvTNaAqvqHchuZqC-70Gr
• http://allegro.tech/2016/03/Managing-Frontend-in-the-microservices-architecture.html
• http://blog.xebia.com/the-monolithic-frontend-in-the-microservices-architecture/
• https://www.infoq.com/presentations/html-components-services

See https://blog.appcanary.com/2017/http-security-headers.html and https://github.com/twitter/secureheaders/

• X-XSS-Protection
• Content-Security-Policy
• Strict-Transport-Security
• X-Frame-Options
• X-Content-Type-Options
• Referrer-Policy
• X-Download-Options
• Enforce Secure & HttpOnly cookie options?

Could be used to load dynamic predicates instead of loading groovy like Netflix did.

Currently needs a url to route. A load balancer URL is lb://serviceid/path, so maybe function://functionname or scfn://functionname.

A bit forward thinking.

/cc @dsyer @markfisher

Analogous to spring webflux functional api

Hi,

As it is, the default behaviour is to fail on client error (ie if the underlying service response is 4xx, the gateway will return a 500 Http error).

I had to modify the org.springframework.cloud.gateway.filter.NettyRoutingFilter class and add failOnClientError(false) to the HttpClientRequest creation (l.79).

I think the failOnClentError(false) should be the default behaviour (transparent gateway), or at least configurable.

Thanks for this awesome project, I'm looking forward to using it ( if you have an ETA, I'd be very pleased ;) )

Would probably need a Servlet implementation of ServerWebExchange so that predicates and filters can be reused.

This was a bad idea, though I tried.

I loved the workflow described https://spatialos.improbable.io/games/grpc-web-moving-past-restjson-towards-type-safe-web-apis

😜 gee, should we really?

Hi,

I need to modify the body of both the request and the response (encryption/decryption).
As I see it, I can create a filter that sets a ServerHttpRequestDecorator in the exchange and override the getBody method, but I didn't find a way to do the same with the response. The WriteResponseFilter is the first filter and consequently the exchange used is the original exchange.
Would it be possible to add a ResponseBodyHandler interface to allow modifying the response body? Or did I overlook something?

Thanks in advance.

In M1 it does not appear to be possible to add a default filter via configuration properties.
Given the following configuration:

spring:
  cloud:
    gateway:
      default-filters:
       - name: filter1
       - name: filter2

with a breakpoint on GatewayProperties::getDefaultFilters I always end up with a single RemoveNonProxyHeadersWebFilterFactory filter which is added via GatewayProperties::loadDefaults.

I can verify that filter1 and filter2 are being created by setting breakpoints in the constructor.

• Add Request Header
• Add Response Header
• Set Request Header
• Set Response Header
• Remove Request Header
• Remove Response Header
• Rewrite Path
• Set Path
• Redirect To
• Set HTTP Status
• Hystrix
• Ribbon (Via Spring Cloud LoadBalancerClient)
• Set Query Param
• Remove Query Param (Might take a PR in spring-framework, would make AddRequestParameter easier).
• Request Size
• Compress
• Spring Retry
• CORS
• Tee (ala unix tee): send one request to two places, ignoring one response from skipper
• Rate Limiting: token-bucket, rolling-rate-limiter (NodeJS/Redis), GCRA go, GCRA Java or here zuul-throttle filter
• Simian Army Filters (latency, random text, bandwidth limits) #64
• Versioning?

See #10 (comment)

Seems there is only memory based implementation now, would be great if it supports persistable repository.

In cd7767e
I moved from Predicate<ServerWebExchange> to RequestPredicate from Spring WebFlux. Now predicates use ServerRequest while filters use ServerWebExchange which is a bit inconsistent.

@dsyer @markfisher thoughts?

A Route locator that looks up queues from kafka or the like and sends messages to the broker.

I tested the sample example, it seems that a.abc.org:8080 does not match **.abc.org. Is that supposed behavior?
However **.abc.org:* matches.

Determine what metrics could be useful and define a strategy for exporting them using boots metrics apis

• Cookie
• Header
• Host
• Method
• Query
• URL
• After Date/Time
• Before Date/Time
• Between Date/Time
• Source IP

See spring-cloud/spring-cloud-netflix#1663

Finical issue.. But UrlRoutePredicate is much more an URI or even simply a Path but not an URL as referenced by RFC https://www.ietf.org/rfc/rfc3986.txt

My Top Choices

• Conduit
• Hub
• Gateway

My Next Choices

• Interchange
• Junction
• Influx
• Ingress
• Jetway
• Onramp

Other Choices

• Airlock
• Passage (way)
• Pipe
• Turnstile
• Highway
• Router
• Convergence

Looks like reactor-core 3.1.0.BUILD-SNAPSHOT has removed a bunch of API's that spring-cloud-gateway depends on eg. Mono.then(Supplier<T, Mono> ..). Re-triggering a build in CircleCI should reveal the broken API's

This is just a feature request - now that Kotlin DSL is being used for defining routes in Spring Web, I feel that it would be great to define a Kotlin based DSL to define Routes for Spring-cloud-gateway.

Try to get some early load metrics for the stability and performance of s-c-gateway.

https://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-7.1.3

Hop-by-hop header fields, which are meaningful only for a single
transport-level connection, and are not stored by caches or
forwarded by proxies.

The following HTTP/1.1 header fields are hop-by-hop header fields:

• Connection
• Keep-Alive
• Proxy-Authenticate
• Proxy-Authorization
• TE
• Trailer
• Transfer-Encoding
• Upgrade

This is a feature request.

The Aggregation Gateway Pattern describes some kind of multi-request endpoint. Example:

Instead of calling GET http://gateway/foo and GET http://gateway/bar as two separate requests, there is an endpoint which can take a single request which contains multiple requests, processes them, and then returns a single response which contains the aggregated responses.

Maybe it's possible to implement this using multipart/mixed (which is basically the same as multipart/form-data but with slightly different semantics).

I'm not sure whether this already exists or if it's necessary at all when using HTTP/2.

Tons of it, there is none.