Support more options to create target objects in `@Argument` binding

[david-kubecka]

I would like to be able to customize how Spring for GraphQL instantiates objects from query/mutation arguments. Example schema:

input type Parent1 {
  child: Child
}

input type Parent2 {
  child: Child
}

input type Child {
  prop1: Int
  prop2: Int
}

type Query {
  createParent1(parent: Parent1): Parent1
  createParent2(parent: Parent2): Parent2
}

I have the corresponding controller methods which follow the standard naming convention and whose arguments are classes Parent1 and Parent2, respectively. These parent classes' structure is the same as the input types but Child class has a different structure than the corresponding input type (e.g. input prop1 is used as an argument to a function that populates target prop3). I would like to be able to define a custom deserializer of the Child class from the internal argument submap.

Currently, I'm achieving this manually, i.e. my controller method looks like this:

@MutationMapping
fun createParent1(@Argument parent: Map<String, Any>) {
  val parentTransformed = parent.findAndTransformNestedChild()
  return mapper.convertValue(parentTransformed, Parent1::class.java)
}

This works but must be repeated for each mutation/parent combination.

Is there a better way how to achieve my use case? I've initially also explored a way to define an input object directive but I couldn't figure out whether/how an input data transformer can be set there.

[rstoyanchev]

Have you tried registering a Converter? You can do that by providing a FormatterRegistrar to AnnotatedControllerConfigurer.

[david-kubecka]

Thanks for pointing out the general direction. Currently, I have this skeleton:

class CustomFormatterRegistrar : FormatterRegistrar {
    override fun registerFormatters(registry: FormatterRegistry) {
        registry.addConverter(CustomConverter())
    }
}

class CustomConverter : Converter<String, Child> {
    override fun convert(input: String): Child {
        ...
    }
}

@Configuration
class GraphQlConfig(val objectMapper: ObjectMapper, controllerConfigurer: AnnotatedControllerConfigurer) {
  init {
        controllerConfigurer.addFormatterRegistrar(CustomFormatterRegistrar())
  }
}

I hope I've done the wiring right... Anyway, I'm struggling to figure out what the converter source type should be. I've tried both String and Map<String, Any> but neither triggers my converter.

[rstoyanchev]

There is some detail missing from the description, so if you want us to take a closer look and give you specific advice, please provide a small sample.

[david-kubecka]

Hi. I've created a sample app that demonstrates the problem: https://github.com/david-kubecka/graphql-custom-converter/tree/main. I believe I just didn't get how the custom converter should be wired into GraphQlConfig and/or what should be the source type of the Converter.

Thank you for looking into this!

[rstoyanchev]

Thanks for the sample.

This case requires use of a static factory method to create the target type, and that's not supported. Currently, we support using a single, public, constructor with arguments, or a default constructor and then binding via properties. The ConversionService is used in addition, mainly to assist with converting scalar values where needed. We could consider an enhancement for what to do when there is no suitable constructor for the target object.

One option is to expand use of the ConversionService to check if it supports conversion from Map to the target type, but the converter would then have to deal with converting sclara values, and potentially with nested ones too. None of these are much of an issue in this case, but not ideal as a general solution.

Another option is to check for static factory methods, but there may be several of them and it could get tricky to select the right one with overloaded methods and/or nested input. Furthermore, such factory methods might not even be on the target type, like the case here where Money.of is used to create MonetaryAmount. Ideally, we just need to be pointed to the factory method to use, and we can handle the rest.

Whatever mechanism we choose could also be useful for selecting among multiple data constructors.