How can I configure a custom ObjectMapper to be used?

[joaodias14]

A little bit of context on this. Our default ObjectMapper is configured to remove non-null and non-empty values from serialized JSON. As a result, the GraphQL schema becomes invalid (because of missing definitions I guess --> https://stackoverflow.com/questions/55925747/graphql-java-error-introspection-result-missing-interfaces).
If we remove the non-null and non-empty configurations from this default ObjectMapper, schema becomes valid.

A solution would be to define a specific ObjectMapper to be used (by KotlinDataFetcherFactoryProvider I guess) instead of the default one available. However, we are not being able to force the usage of such ObjectMapper. We have tried defining our own SimpleKotlinDataFetcherFactoryProvider with no luck (hoping that auto-configuration would not kick in because of @ConditionalOnMissingBean). How can we do this? Many thanks!

Best regards,
João Dias

[dariuszkuc]

Hello 👋
If I understand right your issue is that you need to have two different ObjectMappers? i.e. one that strips the null/empty values from the serialized JSON (guess used for downstream calls) and another one for GraphQL?

If you are using graphql-kotlin-spring-server you can customize default Jackson object mapper as specified in SpringBoot docs, e.g. by creating Jackson2ObjectMapperBuilderCustomizer bean with your custom logic. As for the other one (used by GraphQL), you should be able to define your own custom data fetcher factory provider bean. The default from auto-configuration library is supposed to back-off if you provide custom bean, e.g. following should work

@Bean
fun dataFetcherFactoryProvider(applicationContext: ApplicationContext): KotlinDataFetcherFactoryProvider {
  val objectMapper = jacksonObjectMapper()
  // customization here
  SpringKotlinDataFetcherFactoryProvider(objectMapper, applicationContext)
}

If the above doesn't work please provide a github project that can reproduce the issue.

[joaodias14]

Hi @dariuszkuc,

Thanks for your fast reply. We are currently using 3.6.6 version which does not have SpringKotlinDataFetcherFactoryProvider class. Still, I copied its implementation from your latest 4.0 alpha version to our code but still no luck.
We have even tried to define our own Auto-Configuration class instead of a regular Configuration one with the bean definition you sent but it didn't work either.
Can you please confirm that this should work on 3.6.6 version so that we build a small github project as an example to share with you? Thanks.

Best regards,
João Dias

[joaodias14]

Nevermind. I just understood what you were saying. /sdl endpoint is useless for things like Insomnia or even the Playground that it's included. The schema is always retrieved from /graphql endpoint... I guess there is nothing I can do then.

[joaodias14]

It seems that removing only setSerializationInclusion(JsonInclude.Include.NON_EMPTY) everything works because this was removing stuff like interfaces from schema response to the introspection query request.

[dariuszkuc]

You cannot remove null values from the GraphQL response as that breaks the spec, i.e. if client asks for a field and the value is null it still should be present in the response. If you remove it this will break A LOT of clients.

[joaodias14]

I guess that this depends on the client. If something may be null at some point they must be prepared for it. Having it as null explicitly or simply not sending it would have the same effect on the client-side. Still, thanks for the heads-up.
In our case, we want to remove such null values because our response body is usually huge and by not sending null values we can make it a little bit shorter.

[smyrick]

@joaodias14 As mentioned, by not returning a response that matches the incoming request you are no longer returned a valid GraphQL response per the GraphQL spec and this may have some issues with the various GraphQL client libraries.

If your issue is that you have to many null values, you may want to consider your schema design if the client really needs this data. Another way of reducing response size is to use more lists and nullable fields higher up.

So instead of some response like the following

{
    "first": "hello",
    "second": null,
    "optional": {
        "foo": null,
        "bar": null
    }
}

Instead you can do something like this by not adding null values to lists, and return null for the parent objects

{
    "values": ["hello"],
    "optional": null
}