Override GraphQLArgument object type to provide more details to clients

I’m probably doing this completely wrong, but I have a simple GraphQLQuery where the method signature is essentially

@GraphQLQuery(name = url)
public List<Entity> searchAll(@GraphQLArgument(name="filter") Entity filter) {
return search(filter)
}

That wraps up a matcher search so that some of our clients that want a general purpose search can pass an id into the filter or another attribute and get back a filtered list. The problem becomes that in an attempt to extend this to be able to take nulls, the method signature has to move to being a Map so that we can distinguish when a value is null because it wasn’t set, or null because the client want to search on null (such as figuring out which customers don’t have a telephone number set). So my first issue I ran into is that you can’t have a Map<String, Object> as the GraphQLArgument as I get an error saying

[
"Validation error of type WrongType: argument value ObjectValue{objectFields=[ObjectField{name='id', value=IntValue{value=1}}]} has wrong type"
]

where it doesn’t like converting from an Int to an Object . That’s not the best, but I can set the argument to be an object and then cast it to a map so that it can still be searched like so:

@GraphQLQuery(name = url)
public List<Entity> searchAll(@GraphQLArgument(name = "filter", ) Object filter) {
Map<String, Object> where = ((LinkedHashMap) filter);
return search(where)
}

My issue then becomes GraphiQL which loses information about the argument and can only refer to it as “ObjectScalar”. Is there a way to override how it is reported back to GraphiQL, such as setting a type in the argument so that it can be mapped to the relevant entity in GraphiQL allowing clients to know that the argument should really be in the layout of the Entity?

[chrishunter-agspace]

#notworthy

https://media.giphy.com/media/iiS84hOJXh1Pq/giphy.gif

[kaqqao]

I don’t mind extending the discussion. Better clear it up than have you confused 😃

Unless there’s a setter for subEntities exposed (i.e. setSubEntities), or you configure your Jackson to use reflection (I think there’s such a setting) or have a @JsonCreator constructor, the default InputFieldDiscoveryStrategy will ignore that field when mapping EntityInput. Since InputFieldDiscoveryStrategy only delegates to Jackson, it’s better to reconfigure Jackson than mess with the strategy itself.

As a general rule, I wholeheartedly recommend exposing service classes that work with DTOs, instead of DAO/repository classes working with domain objects/persistent entities directly, so yeah, that’s probably a good idea in your case too in any case.