Aggregation Gateway Pattern / Batch request / multipart request about spring-cloud-gateway HOT 8 CLOSED

This is a difficult one

from spring-cloud-gateway.

Can you tell why this is difficult?

The only possible reasons I can see are:

• Timeouts
• Things like Server Sent Events (SSE), Streaming, WebSockets. (basically every thing with infinite data streams)

Or is there something wrong/missing/impossible with multipart/mixed?

If the problem is the CPU load / memory usage for the API Gateway, because it could take a huge amount of memory to buffer all the response data while waiting for the slower requests to finish. Then multipart/parallel might come in handy.

EDIT: Here's an example of Gmail's implementation: https://developers.google.com/gmail/api/guides/batch

from spring-cloud-gateway.

Long running connections wouldn't be possible. Usually, this gets into business logic and ends up as with some kind of dynamic programming in properties. It would have to avoid that kind of thing.

from spring-cloud-gateway.

The difference with gmail is the only endpoints that can go in the batch are other gmail endpoints and batch knows the limitiations. This would be the difficult part, or the part that would need to be documented well.

from spring-cloud-gateway.

Yeah, that's completely true.

But I'd add this: The API User is still a human who must think about what he/she's doing! Doesn't matter if he/she calls lot's of single endpoints or a batch endpoint.

I think that Spring API Gateway knows all its endpoints, too. Or am I wrong here?

Maybe this feature could be added as an extremely simple proof of concept. With a huge BETA note. In the first iteration it could simply accept every multipart request and execute it. Later on properties could be added to whitelist or blacklist certain requests, specify timeouts, etc.

from spring-cloud-gateway.

This pattern is used a lot in a distributed architecture.
Something should be done to make this task easier and take advantage of Spring Gateway.

from spring-cloud-gateway.

I think our current advice for this is a Backend For Frontend or use the spring-cloud-gateway-webflux module to write a controller that does this in the gateway (using a forward:/<controller> route.

from spring-cloud-gateway.

I think our current advice for this is a Backend For Frontend or use the spring-cloud-gateway-webflux module to write a controller that does this in the gateway (using a forward:/<controller> route.

I have done a lot of research about Api Gateway Pattern.

1. I think we should avoid to do aggregation works including business logics in the gateway. The problem mentioned at Overambitious API gateways by Thoughtworks Rader
   

2. BFF aims at different user experience clients. Adding a BFF concept and managing it would be an overhead if you just want to optimize the comunication latency caused by multiple requests through WAN.

3. Microsoft Graph Docs shows the batch api which follows OData Batching Request Specification, I think this is the right way and important feature for gateway product.

4. There is an opening issue about this feature in Kong/kong, but it is not implemented yet.

I am so confused, why batching request/batching proxy is not proposed as a microservice gateway pattern clearly ?

According to many similar ariticles about gateway, Api Gateway Pattern is different from Batching Request/Batching Proxy Or is not clear enough to lead you to this practice.

from spring-cloud-gateway.