How to define multiple DownstreamPathTemplates to work for one UpstreamPathTemplate?

[fdevGit]

Hello,
quick question: How to set up an incoming request to redirect to more than one endpoint?

I'm thinking something like this, I will meet at separate endpoints for both the function and the counter of a request.

Regards !

[fdevGit]

@TomPallister

[raman-m]

Tom is very busy with other projects in production of current employer! He doesn't read Ocelot messages and notifications from GitHub.

[bwn-z]

I thought it should be at the load balancer level

ocelot --> loadbalancer --> instance1
                       |--> instance2
                       |--> instance3

[raman-m]

It could be one of multiple possible solutions. But the author has to write custom load balancer and attach it to Ocelot pipeline.

[fdevGit]

@bwn-z load balancer only provides routing to one endpoint. I want to forward one incoming request to two different endpoints

[raman-m]

Possible solutions:

• Custom middleware. Low level development of Ocelot core & pipeline. Fork Ocelot repo to your account. Use the DownstreamRequestInitialiserMiddleware class and reimplement Invoke method. I hope it is the right place to code your implementation.
• Custom Delegating handler, as @ggnaegi already suggested you.
• Custom Providers of Service Discovery feature. But I am not sure if Ocelot redirects to multiple downstreams or not, in case of multiple services being returned by custom provider. It should be checked.

It is up to you which approach you will use. I'm not sure on the best option to go, it requires some research which takes time. But it seems custom delegating handler is the simplest solution.

[ks1990cn]

@fdevGit Just want to hit two enpoints means? you can use HttpClient from polly libraray and in same controller you can call two endpoints.
Ocelot is api gateway, these things are not part of gateway instead you need your backend logic for it.

@ggnaegi @raman-m I don't think any action needed here, we can close if answer is right.

[raman-m]

What is right will be decided by the author.

Your lemon-like solution with ASP.NET controllers is not an option because the author would like to use Ocelot routes only (for one UpstreamPathTemplate).
Yes, currently it is impossible, but a custom solution can be developed.

[ggnaegi]

@fdevGit You could implement your own delegating handler https://ocelot.readthedocs.io/en/latest/features/delegatinghandlers.html and call the counter endpoint from there with HttpClient.

[ks1990cn]

@ggnaegi I have question here: if anyone add some time consuming logic in SendAsync method, will it slow down application startup time or any time for request to reach controller level of same api?

Just trying to understand should be this preferred way if anyone have time consuming job before calling any other endpoint?

[raman-m]

Yes, delegating handlers for a specific route, aka multiple delegating handlers.
One more detail on definition. The docs says:

Finally if you want Route specific DelegatingHandlers or to order your specific and / or global (more on this later) DelegatingHandlers then you must add the following json to the specific Route in ocelot.json. The names in the array must match the class names of your DelegatingHandlers for Ocelot to match them together.

"DelegatingHandlers": [
    "Instance1Handler",
    "Instance2Handler",
    // more instances
]

I believe the author can go with this approach, but...

1st issue, it answers on author's question partially... We define multiple doewnstreams as delegating handlers of one upstream.
But the questions was "define multiple DownstreamPathTemplates"...

2nd issue, what to do with responses from multiple downstreams? I have no idea how delegating handlers prioritize responses.
And this is the problem! In docs I have not seen concrete answer about responses from delegating handlers, and how them processed.

I guess we have to ask the author, what would he like to do with responses from multiple service instances? Ignore or track?
If track then how? How to merge responses and status codes?

Finally, I believe the author would like to analyze and merge all responses from multiple service instances, and in this case his question is about Request Aggregation feature. 😃 But, again, aggregation requires to define multiple routes with keys, and then merge to one aggregator response. I guess the author would like to have all responses from all instances, that's why he should go with Request Aggregation feature, right?

@fdevGit Dear Tugay,
In my opinion, you can go with Request Aggregation feature because it has one "UpstreamPathTemplate" and multiple "DownstreamPathTemplate" props of explicit routes.
But remember, from Gotcha’s / Further info:

Aggregation only supports the GET HTTP Verb.

What do you think? Is it acceptable to use Request Aggregation feature having GET verb in all downstreams (instances)?