-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Description
Hi 👋
Nullability in GraphQL is a topic much discussed these days (see nullability panel at GraphQL Conf 2024 for a good recap of the current discussions).
I was talking with @StylianosGakis and I understand their team at Hedvig has non-nullable schema by default:
type User {
name: String!
email: String!
}This is a problem today because if an error happens on email, the null bubbles and the whole user becomes null.
As the queries grow, they would like the possibility for clients to handle individual field errors without looking into all sorts of workarounds like splitting a big query into a ton of smaller ones.
One option being discussed is the possibility to have a @noBubbling directive that disables null bubbling for smart client that are able to handle them:
# Allow the server to return null in non-null position if an associated error is returned
directive @noBubbling on QUERY | MUTATION | SUBSCRIPTION
query GetUser @noBubbling {
user {
name
email
}
}If email fails, with @noBubbling, the server can still return name:
{
"errors": [{"message": "oops", "location": ["user", "email"]}],
"data": "user": { "name": "foo", "email": null }
}This was discussed in the nullability working group alongside other solutions such as strict semantic nullability or semantic nullability schemas.
In order to move the different proposals, having real life feedback from the field is critical and @noBubbles feels like a simple solution that would yet address a concrete real life use case.
Would the team be open to adding it under an experimental flag?