We should offer a wiring validation (and maybe mapping validator)

[andimarek]

RuntimeWiring is very silent at the moment when you configure it wrong: a wrong type or not existing field registered is just accepted.

This leads often to subtle problems, especially when bootstrapping or just prototyping something.

We should offer a simple Validator test util or maybe make the Wiring optionally more strict.

A more complex problem: The return type of a DataFetcher could be validated against the Schema. When you return for example a Dog object and the DataFetcher is registered for a type returning a Dog we could validate that the field of Java class type Dog matches the Schema type Dog. This needs more exploration/discussion.

[bbakerman]

Can we give more concrete examples of problems that would be solved

The return type of a DataFetcher could be validated against the Schema. When you return for example a Dog object and the DataFetcher is registered for a type returning a Dog we could validate that the field of Java class type Dog matches the Schema type Dog.

How? Java type erasure means we can know that a DataFetcher is declared as DataFetcher<DogPojo> ??

Also do we need to do this in the runtime schema? Is this not a schema post processing step? graphql.schema.idl.SchemaGeneratorPostProcessing is a callback ready for this today??

[github-actions]

Hello, this issue has been inactive for 60 days, so we're marking it as stale. If you would like to continue this discussion, please comment within the next 30 days or we'll close the issue.

[bhabegger]

In complex wiring scenarios you may want to be able to test that your wirings are as you would expect them to be. So here maybe one step would be to provide facilities to help testing that your runtime wiring matches your expected wiring.

given:
my wiring setup

when:
I plug everything together

then:
this concrete Type.field is wired using this DataFetcher class.

[bhabegger]

Also you might want to check things like cardinality. A list field needs to be wired to a data fetcher outputting lists and a signleton datafetcher need to output single objects.

[dondonz]

Coming back to this old thread 😄

Ideas about wiring validation have come up a few times in discussions so I'll add the latest developments here.

In v22.0 we've introduced an optional "strict" mode for RuntimeWiring and TypeRuntimeWiring. In short it'll complain if there's an attempt to set a datafetcher on a field that's already got a datafetcher registered. #3565

In terms of more powerful wiring validation, Spring for GraphQL has a fantastic "Schema Inspection" feature which will tell you where datafetchers are missing, which avoids nasty runtime problems! Have a look at their documentation here: https://docs.spring.io/spring-graphql/reference/request-execution.html#execution.graphqlsource.schema-mapping-inspection

There are challenges with bringing a similar schema inspector into the lower GraphQL Java engine level, to explain why we didn't implement it yet.