Issues with response serialization

[owengalenjones]

Hello, I'm a little unclear about how to go about using Jackson to serialize objects. I have an annotated POJO:

public class Foo {

@JsonProperty("bar")
private String something;

// getters / setters
}

and am invoking GraphQL through the DGS framework:

return executor.execute(
        body.getQuery(),
        body.getVariables(),
        body.getOperationName(),
    );

The data property that I get back is an Object typed LinkedHashMap that does not appear to have followed the Jackson annotations:

ExecutionResultImpl{errors=[], data={library={something=bad}}, dataPresent=true, extensions=null}
data LinkedHashMap
  "foo" LinkedHashMap
    key = "foo"
    value = "something" -> "bad"

It appears that something has per-emptively changed the type to LinkedHashMaps prior to running Jackson serialization, resulting in the actual field names, not the annotated JSON properties.

If I manually serialize it I get the expected result (the property obeys the @JsonProperty annotation):

new ObjectMapper().writeValueAsString(foo);
=> {"bar": "good"}

I tried to override the ObjectMapper but I still see the same behavior.

[cesar05]

Hello, I'm trying to do the same but it doesn't work for me.
@owengalenjones You have additional information. Could you solve it?

[owengalenjones]

Hi @cesar05 no I don't have any additional information. Maybe we should file an issue as this got no traction.

[kilink]

If you're calling using a DgsQueryExecutor and just getting an ExecutionResult, Jackson / JSON serialization doesn't come into play at all. This is the response as returned by graphql-java. If you're talking about making an HTTP request to /graphql in your app, which is handled by the DGS controller, then that execution input gets serialized by calling toSpecification() on the ExecutionResult and serializing THAT to JSON using Spring. I think we would need more details, as it's unclear what you are actually trying to do (what does your query look like?). The returned format follows the GraphQL specification, so yes, the data in the result is a Map. What does your schema / query look like here?

In short, there is no way to control what is returned in the data property directly. For Scalar types, you can control things via a Coercing implementation registered as a bean. If your GraphQL schema doesn't match what your pojo looks like, you need to register a custom PropertyDataFetcher to map the schema name to the pojo getter / field.

[cesar05]

Example: What I want to achieve.
How could I get the expected result?

type Query{
    getUser:User
}

type User{
    id:String
    first_name:String
    email:String
}

@DgsComponent
public class ConfigMapper {
  @Bean
  public Jackson2ObjectMapperBuilder jackson2ObjectMapperBuilder() {
    return new Jackson2ObjectMapperBuilder()
        .propertyNamingStrategy(PropertyNamingStrategies.SNAKE_CASE)
        .serializationInclusion(JsonInclude.Include.NON_NULL);
  }
}

@DgsComponent
public class UserService {
  record User(String id, @JsonProperty("first_name") String firstName, String email) {}
  @DgsQuery
  public User getUser() {
    return new User("1", "dgs", "dgs@dgs.com.co");
  }
}

Result:

{
    "data": {
        "getUser": {
            "id": "1",
            "email": "dgs@dgs.com.co"
        }
    }
}

Result Expected:

{
    "data": {
        "getUser": {
            "id": "1",
            "first_name": "dgs"
            "email": "dgs@dgs.com.co"
        }
    }
}

[kilink]

JSON / Jackson serialization is not involved here at all. If your schema field name diverges from the getter name of your POJO, you need to register a custom DataFetcher (see the graphql-java docs here). By default, graphql-java will try to find a getter that matches the name in the schema.

Here's a solution from a similar reported issue.

[cesar05]

Thank you very much for your response, now I understand the problem and what the solution was. Similarly, in the thread you shared with me, I understand that work will be done to facilitate this task in the GraphQL layer. If that's the case, is there any estimate of when it could be ready?

[srinivasankavitha]

Hi @cesar05 - we do not have plans of doing work to facilitate this use case. This is not common usage and as mentioned in the solution thread, you can always add your custom handling.