Make the unadorned type non-null?

[martinbonnin]

Edited in March 2025 to explicitly mention the unadorned type

This is a follow up from #63.

GraphQL best practices are currently to use nullable types by default.

This is reflected in the syntax by the fact that String is a nullable type. That is in contrast with languages like Swift and Kotlin where String is non-nullable and the nullable type has a ? modifier: String?.

With all the work going on in the nullability working group and the advent of semantic non null types, feels like now is a good time to revisit. Should the unadorned type be non-null?

This issue is for gathering community feedback and use cases. Would you rather keep the current unadorned type nullable by default? Or change it to non null by default?

[martinbonnin]

This was discussed there.

There are 2 different things:

1. Best practices: change the GraphQL best practices to use semantic nullability when possible: make the schema describe the types with precision and uncouple error considerations from purely type considerations.
2. Syntax: make the syntax match the best practices.

Looks like 1. has reach some sort of consensus and could be achieved more easily than 2. See https://github.com/graphql/graphql-wg/blob/main/rfcs/SemanticNullability.md and other discussions in the nullability-wg.

[benjie]

I don't think we're changing best practices to "use non-nullable by default" - in fact, I think that's terrible advice.

Instead, what we're saying is:

represent the true nullability of your data

I.e. do not factor potential errors into your nullability choices.

If a field has null as a valid value, then leave it as nullable - for example email: String because email is optional. Don't make it non-nullable and then use the empty string to represent "no email" - that's hideous.

If you're not sure whether a field may ever represent a true null in the future (for example you might require a phone number for people to register with your short messaging service, twttr, but are you certain that you will always in the future require a cell phone number?) then you should still use nullable by default - you can always add the "actually, this will never be null" constraint in the future, but you can't go the other way without breaking clients who don't know how to handle a null phone number (user.phoneNumber.replace(/^00/, "+") - OH NO, CRASH!).

[martinbonnin]

I don't think we're changing best practices to "use non-nullable by default" - in fact, I think that's terrible advice.
represent the true nullability of your data

I think we're saying the same thing:

1. Best practice should be to represent the true nullability of the data
2. Whether the syntax uses non-null by default is a separate (and somewhat harder) problem

The initial title and description of this issue wasn't clear, I have edited it to reflect that it's about 2.