CCN: A path to True Nullability Schema about nullability-wg HOT 3 CLOSED

@benjie Thanks for taking the time to read, and for your thoughtful feedback. I've put together some thoughts in reply:

I find myself wondering if we actually want field-level ? at all, or if just a whole-query "don't worry, I'm smart enough to handle the errors myself" is sufficient.

Yes, agreed. CCN's ? was what first got me thinking "what if the client could just opt out of null bubbling?", but it would just be a means to an end. I've since made a discussion post in the main Working Group Repo True Nullability Schema which approaches the idea without assuming any connection to CCN. At the end of the day, this approach just requires some way for smart clients that can handle errors client side to ask to opt out of null bubbling.

In outputs, it's both "can be null" and "is an error boundary".

Right. And if we can opt out of null bubbling, then we are left with jus the "can be null", which is much easier to reason about.

Regarding the potential for a once non-nullable field to become nullable is valid. I call out a version of that in the "breaking changes" section. However, data semantics are always going to be change over time in all sorts of ways. I'm not sure a field becoming nullable is a special case of this. It is our job as schema engineers to anticipate these changes when they are likely (making a field nullable in anticipation of a likely re-architecture) or managing the work of a breaking change (deprecating a field and replacing it new a new nullable one).

It almost feels like there should be a different indicator, like "seems like a good place for an error boundary".

My hope is that we can start to rely more heavily on the errors metadata to represent errors which would obviate the need for error boundaries in the schema all together.

In other words, in this new non-bubbling mode, the server makes a different, slightly weaker, assertion. Rather than "The data portion of my response is always type-safe with regards to the schema" instead it says "The data portion of my response, ignoring any fields referenced in the errors metadata is always type-safe with regards to the schema"

from nullability-wg.

Thanks for writing this 👍 . About your question:

[...] It allows us to turn a non-nullable field into a nullable field as a non-breaking change. [...] I am curious to learn how well it works in practice. Have users of this approach actually be able to routinely make fields nullable without breaking old clients?

Working on Android, I have anecdotal evidence this is not working in practice.

Quite the opposite actually: the moment the backend starts sending null for something that clients always assumed to be non-null, not only client will break but any preprod/CI check that could have detected this completely ignores it because the field was nullable in the first place and considers this compatible while, in fact, it's a big change of the initial contract.

So it's "technically not breaking" in theory but since clients don't know how to handle the null case and often don't prepare for it (maybe they just don't have a way to test it, maybe they're new to GraphQL, maybe they're on a tight deadline, etc...) then it becomes quite breaking in practice...

from nullability-wg.

Excellent write-up and interesting idea.

This means Relay can auto-insert ?s on all non-nullable fields, ensuring resiliency [...]

Relay would need to auto-insert ?s on all fields, since any nullable field could become non-nullable at a later point as what is currently a non-breaking change; but with CCN any type change could become breaking.

As an alternative, I've wondered if simply tagging the operation as "everything is nullable" would be sufficient:

query MyQuery($id: ID!)? {
  viewer { ... viewerFragment }
}
# ...

This would, in my opinion, be much cleaner than adding ? to every single field. I find myself wondering if we actually want field-level ? at all, or if just a whole-query "don't worry, I'm smart enough to handle the errors myself" is sufficient.

Nullability in GraphQL mixes a few concerns. In input it's both "optional" and "nullable" (which are distinct concepts, but GraphQL merges together). In outputs, it's both "can be null" and "is an error boundary". Your idea of exposing the "true" nullability is an interesting one, and would be an improvement for many developers, but figuring out where to add the ? (if not everywhere, as would be the case for Relay) would be challenging. Referential integrity in a database might guarantee that if a post exists, then the author of the post exists. But as you scale, you might move the post and the author onto different microservices, and suddenly the fact you could fetch a post no longer means you can fetch the author. The client has no way to "know" this is a possibility, other than the nullability of the field. It almost feels like there should be a different indicator, like "seems like a good place for an error boundary". (Not "field can raise error" because everything could error! More like: does this make sense as a boundary point for errors to stop at?)

from nullability-wg.