Issue with Aggregator in Ocelot: Requires At Least Two Routes to Execute about ocelot HOT 11 CLOSED

@ggnaegi Oh, no!
We forgot to check this user scenario before the release 😏

Ouch...

from ocelot.

if @camilocalderont wants to do it himself, why not?

from ocelot.

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.

from ocelot.

@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.

from ocelot.

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!

from ocelot.

@ggnaegi Oh, no!
We forgot to check this user scenario before the release 😏

from ocelot.

@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.

from ocelot.

@camilocalderont Dear Camilo,
Where are you?

from ocelot.

@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?

Voting

• @RaynaldM 👎 ➖ by the vote
• @raman-m ➕➖
• @ggnaegi ➖ by the vote

Total 2.5 negative of 3

from ocelot.

@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 👍

from ocelot.

@camilocalderont
Dear Camilo!
Sorry, but we didn't accept the issue for development!
There are 2 reasons for that

• In version 23.1 we enhanced Multiplexer (see release notes). And with one route Aggregation logic simply skips Aggregation main block and behaves as standard route. This change was introduced because of performance. So, your IDefinedAggregator will not work! It will not be called!
• I guess your current life hack with 2nd fake route is acceptable solution. Fake route should return empty data or small data block which you will ignore for sure when parsing JSON data.

We will be glad to review your open PRs in future!
Stay with Ocelot! 🐯

from ocelot.