Is using Delegating Handlers good for Response Normalization with Ocelot?

[goliveiracod]

Hi everyone,

Suppose I'm using Ocelot to handle redirection for numerous microservices within my platform.

For some of these microservices, I need to normalize the responses. For instance:

Microservice A provides the following response:

{
    "USERID": "123",
    "NAME": "John",
    "LASTNAME": "Doe"
}

And I need to normalize it to:

{
    "userId": "123",
    "name": "John",
    "lastName": "Doe"
}

Before sending the response back I was considering using Delegating handlers to achieve this.

For simple services, I can do it dynamically:

var userId = jsonContent.RootElement.GetProperty("USERID").GetString();
var name = jsonContent.RootElement.GetProperty("NAME").GetString();
var lastName = jsonContent.RootElement.GetProperty("LASTNAME").GetString();

var normalizedContent = new 
{
    userId = userId,
    name = name,
    lastName = lastName
};

However, for more complex services, it would be ideal to create classes for typing and potential reuse.

My main question is: am I using the Delegating handlers appropriately?

Is the Ocelot Gateway approach for this kind of task?

[RaynaldM]

Yes

[raman-m]

Hi @goliveiracod !
Not much good as you can imagine.
Technically you can use Delegating Handlers feature to transform data with Ocelot app.
You can even use Request Aggregation feature to encapsulate transforming/parsing data logic inside of FakeAggregator.
But doing this will be a bit strange from design/architecture point of view.
In my opinion, Ocelot app should not parse, transform response body at all, because of high load on Ocelot's hosting infrastructure, consuming high machine resources, and having less possibility to process many requests, requests per second ratio will be dramatically downgraded.
So, I recommend to use client apps to parse/transform response data of Ocelot upstreams.

[goliveiracod]

Hi @raman-m

It still seems advantageous for my use case, as it won't always happen, so it makes sense to use Ocelot. It's better to have occasional parses in the Gateway than to build an extra microservice to take care of occasional parses, both will consume resources.

[raman-m]

No problem! But use data transformations for exceptional routes only, because it will consume app resources.

[RaynaldM]

In production, with a lot of requests, half of which we use delegatingshandlers to map parameters to input and results to output (the aim being to "hide" the use of new api from former users).
This consumes a few resources, but not that many.

To bounce back on @raman-m's comments, that's why we use Ocelot (vs. well-known Bla-bla-bla gateway), for its ability to put code between downstreams and upstreams. For me, this is Ocelot's greatest strength.

[raman-m]

@RaynaldM A penalty for mentioning Bla-Bla gateway 😃

[goliveiracod]

I appreciate your replies, it's certainly clearer now 😄