Closed camilocalderont closed 5 months ago
Hi @camilocalderont !
You needn't to develop aggregator classes.
Use Delegating Handlers feature!
But current restriction to have at least 2 routes is quite natural thing when combining 2 sources of data.
But, make sense to remove this restriction.
When developing aggregator you work with DownstreamResponse
object.
When developing delegating handler you work with HttpRequestMessage
and HttpResponseMessage
objects.
But currently, you need to develop custom Http handler which allows you to transform content both of request and response, HttpRequestMessage
and HttpResponseMessage
objects.
In your user scenario, you want to convert data of the response, thus you have to work with HttpResponseMessage
object!
Hope it helps!
@ggnaegi Oh, no! We forgot to check this user scenario before the release 😏
@ggnaegi Oh, no! We forgot to check this user scenario before the release 😏
Ouch...
@RaynaldM @ggnaegi If not joking... Do we accept it?
His feature request is processing single route by Aggregation (multiplexer) middleware.
So, he wants to process single route by IDefinedAggregator
class to convert/analyze data of the response and return converted result to upstream finally.
Current restriction by validators (I guess) is having at least 2 routes with aggregation keys to define an aggregator in Aggregates
section.
To be fair, as I recommended, such data conversions can be performed by custom delegating handler.
Is this sufficient argument to start development for multiplexer?
And, seems the author doesn't care about his issue anymore: so, it could be closed after our decision.
@camilocalderont Dear Camilo, Where are you?
if @camilocalderont wants to do it himself, why not?
Hi, @RaynaldM, @raman-m, I greatly appreciate your attention to my case. I'm a big fan of Ocelot and use it daily as an orchestrator service and even as an entry point.
Your alternative is very good, but in my case, I use a class to organize and dynamically change the host and port. Therefore, it was better for me to use Aggregators instead of Controllers, as it would duplicate an endpoint that is already in another .Net project being orchestrated. Thus, I had to use an Aggregator and define 2 routes, but only use the first one.
It would be nice to not have that restriction.
@camilocalderont
Thus, I had to use an Aggregator and define 2 routes, but only use the first one.
Sounds like a life hack! 🤣 You are true Ocelot fan! 😉 Imagine we will disable 2 routes validator for Aggregation. What's the goal? Just remove fake route from JSON? My vote weight is 0.5. I neither refuse nor accept at this time.
@ggnaegi Your opinion?
Total 2.5 negative of 3
@raman-m @camilocalderont @RaynaldM By design, if only one route, then when don't make any further checks and process the downstream request. It's a bit straight forward, but that's the way it is at the moment. The problem is probably that the Aggregator has been placed at the wrong spot in the multiplexer and we are mixing concerns. From my side I would prefer moving the Aggregator somewhere else in the pipeline, renaming it, and calling it ResponseTransform instead.
@ggnaegi Your vote is negative, right? ➖ Regarding middleware name... It doesn't matter for me, and I don't see a benefit in renaming. Regarding a position in the pipeline... It makes sense to find appropriate and right position 👍
@camilocalderont Dear Camilo! Sorry, but we didn't accept the issue for development! There are 2 reasons for that
IDefinedAggregator
will not work! It will not be called!We will be glad to review your open PRs in future! Stay with Ocelot! 🐯
Expected Behavior / New Feature
Aggregators in Ocelot should execute correctly when configured with a single route, allowing modifications to the response as per the aggregator's logic.
Actual Behavior / Motivation for New Feature
The aggregator does not execute when it is configured with only one route. Instead, the request seems to be handled by another route with a wildcard, and the response from the microservice is returned without any modifications by the aggregator.
Steps to Reproduce the Problem
Specifications
Docs