Allow graphql resolvers to return data even when fields are missing from schema

[Joe Polastre]

Issue

Hello,

We have a use case where the client may be ahead of the server version. This often happens when the server is located in an offline or disconnected environment. As the graphql schema gets modified forward in a non-breaking way, the client starts using the new schema capabilities. When it runs into a server that has not yet been updated, it results in a null gqlgen response and a validation error corresponding to the FieldsOnCorrectType rule.

The graphql specification and related best practices are clear on non-breaking changes where the server is ahead of the client. However the spec appears silent on expected behavior in the other direction, which is our use case.

Proposal

We propose a gqlgen configuration option allowUnknownFields that is disabled by default. This option would permit unknown fields to pass validation but be returned as null in the response object. An error could also be added to the graphql response indicating this is an unknown field, however all of the resolvers are permitted to run and return data as per usual.

Implementation

This requires changes to executor.go to check which rules failed validation and to the object.gotpl template to return a nil graphql value.

We would be happy to provide a PR with these changes.

Would you be willing to accept such a contribution?

[tony]

This is definitely a good add. In the interim would it be a good move to ensure that the backend and the client stay in sync in regards to query expectations? For example, while a feature may have not yet been implemented on the server side from a logic perspective, could a default response be mocked out server side? This could allow the client to successfully make the "new" query without it failing due to the resolvers not yet being implemented server side.