Their syntax is quite similar even if the defaults are different and if the details of handling null vs absent can get complicated for input values. GraphQL and Kotlin are a good fit: they are both strongly typed and have nullability built-in. This can be surprising at first, but it makes sense when you think about it: the 1st Optional represents the presence or not of the value, the 2nd one represents nullability. 💡 With input values and operation arguments, you may encounter things like Optional>.

annotating the fields with or wrapping nullable types in OptionalĪpollo Kotlin can do both, with several flavors to choose from for each.Java doesn’t have a strong support for nullability, but there are tools that can help: In addition to Kotlin, Apollo Kotlin can also generate Java code. This can also be configured once globally if preferred. 💡 By the way, notice how the GraphQL and Kotlin syntaxes are quite similar, but an important difference is how the default in GraphQL (no !) means nullable, whereas the default in Kotlin (no ?) means non-nullable. When selecting a field whose type is nullable in the schema, the corresponding field in the generated Kotlin model will also be nullable. Null safety on fieldsĪpollo Kotlin generates models based on your project’s GraphQL operations and the type information found in the schema. Let’s look at a few ways the library deals with nullability.

In fact, nullability is one of the key features of GraphQL, allowing API authors to clearly specify which fields of a type are nullable.Īs for Kotlin, the language supports nullability in its type system, significantly reducing the risk for errors – for example assigning a potentially null value to a non-nullable field won’t even compile!Īt the intersection of these two worlds lies Apollo Kotlin, the GraphQL typesafe client library for Kotlin. Mistake or not, null is here to stay and there are ways to coexist peacefully! The concept of null is sometimes called a “ billion dollar mistake”.

Kotlin is null