Same Request to multiple endpoints

[amarcoaldi77]

Hi guys!
I would like to know if is there a specific configuration to send same request to more than one backend, wait for all responses and select one of this responses as outcome message. Thanks.

[predic8]

Hi @amarcoaldi77,
there is no functionality that does exactly what you described. Can you describe the use case a bit more in detail and the motivation like loadbalancing, filling a test env or reliability. Then we see if there is something or if we can add a new feature.

[amarcoaldi77]

I try. Sometimes you need to train a second environment with same request that you want send to the primary system. Probably because, in a short time, you want switch from the primary endpoint to this secondary endpoint. In this interval you wanna know if that secondary system evolve in the right way with the same request that you send to the primary environment. It's like a fork of the request that came to a primary environment and then arrive to a secondary (or third,...) backend too. Other feature the ability to send the same request to N system (like risk analysis engine) that perform a task and respond with a specific risk score. On the api gateway you wait all the responces (with a timetout) and select the more restrictive response to emit.
P.S. congratulations for the splendid work!

[predic8]

Hi @amarcoaldi77,
thanks for the description. That sounds like a requirement we also have at the moment. We get calls from the outside into our production environment. We need those events for the test system too. Just copy the static data will not do the trick. We need the stream and the distriubtion over time.

We are planning to add a kind of splitter, that

C-------> Membrane -----> Backend Production
                         |
                         |-----------> Backend Test
                         |
                         |----------->  Backend Dev

Instead of waiting for all three we planned just to call production regularly. The calls to the other backends will be executed asynchronously and should not slow down production. If a call to test or dev fails, we log it but we will ignore the error.

It is important that all the environments get the calls to have almost identical data to test with.

Maybe that is close to your needs. Otherwise maybe it is possible to make it configurable to match your case too.

[amarcoaldi77]

Great! Thanks for your reply. Hope to test it soon.

[christiangoerdes]

We have been planning this feature for a while, issue #1140 describes it.

[t-burch]

@amarcoaldi77 feature has been canned, branch "parallel-interceptor" has a working prototype, but it doesn't stream the body which makes it potentially slower with large requests. Examples are included as well.

Master version will only support traffic shadowing, not the full customizable strategy system. So the only feature is duplicating requests in the background without being able to interact with them.

[christiangoerdes]

The traffic shadowing functionality has been merged into the master branch. For configuration details, refer to the shadowing example

[amarcoaldi77]

Hi guys! Great Job!
I tested it and i have some questions:

1. Shadowed Request has always GET verb. Why? I think it should use the same HTTP verb of the original request.
2. Heders of the original request are not mapped on shadowed requests.
3. In shadowed Requests the path of the request is always blank (protocol, host and port are correctly remapped).

Maybe i'm using a wrong configuration but i review the code and i think that these are choices and not bugs. Is it true?

[christiangoerdes]

Thank you for your feedback! We’ve implemented the following: shadowed requests now use the same HTTP method, headers are mapped correctly, and the full request path is remapped. We've also ensured that shadow requests contain the original headers when reaching the ShadowingInterceptor, so subsequent interceptors like AddHeaderInterceptor won't affect them.

[Lucamadio]

Hi @amarcoaldi77,
i tried to solve the issue in the ShadowingInterceptor class passing the missing data from the original exchange and set the new exchange object in a refactored version of the method cloneExchangeAndSend(...).

I'm not sure this is the right way to accomplish it, hope it is helpfully.

[t-burch]

We have already worked on a solution, but thank you for your contribution!