OlegIlyenko
commented
9 years ago Main reason for this is to make schema definition more idiomatic scala. In scala we used to Option type so it is reflected in the schema DSL. I actually initially started with NotNull type, but quickly realized, that it makes it very hard to define any type-constraints in scala based on this type. So also from scala type-system perspective it is advantageous.
We once discussed it in graphql repo, and it turns out that this practice also encouraged by graphql spec maintainers:
I strongly support this approach. Ultimately, the default for nullability is a moot-point when you have good GraphQL core libraries which respect the ergonomics of the particular language or environment. For strong typed languages that replace the concept of null with Maybe/Option/Either, I would expect to use a GraphQL library in exactly the way you define.
https://github.com/facebook/graphql/issues/63#issuecomment-123104787
luisobo
Apparently sangria makes all fields non-nullable by default and it introduces the OptionType type to make a field optional. The spec works the opposite, making every field optional and having the non-null type to make fields as mandatory.
What was the rational behind this decision?
Thank you, I'm loving sangria.