On the 22nd of March, you had a talk at Android Ma...

# apollo-kotlin

[Stylianos Gakis]

On the 22nd of March, you had a talk at Android Makers. I was looking for it to re-watch something but I realize it’s not on their YouTube channel. Is it available somewhere?

[mbonnin]

It's coming next week I think

[mbonnin]

We didn't want to release videos in the middle of Google IO

[Stylianos Gakis]

Right, that makes sense!

I wanted to look at the part where you talked about partial responses. Specifically, we’re not using them right now, we are just returning a failed result if there are any errors. We were exploring potentially using it for some places where we thought it might make sense.
My thought was simply that I’d like to better understand the drawbacks of doing so. Now since we don’t allow it, we can always use non-null objects if the schema defines them as such, since we know if anything went wrong we are not going to try to access them.
If we do however allow partial responses this will no longer be true right? That’s what you showed once in that talk which I wanted to rewatch basically.

I was now reading the errors section of the docs, and it does say that if there is an error with something being null in a non-nullable field, it will bubble up and make the first object it finds going up the tree that is nullable. However I wonder what happens if there is a query that has say 5 “top level” queries that it calls and they are all defined with a non-null return type but one returns null since an error has happened? There’s nowhere to bubble up from there right? For that case it says In the worst case, response.data can be null if everything else is non-nullable., so I assume in that case we simply can not use partial responses.

Would the solution then be to have to define all of those queries as returning a nullable to be able to use partial responses? That would require a schema change too as I understand it.

[mbonnin]

You got everything 100% right. When an error bubbles it will "discard" all data in siblings

[mbonnin]

The GraphQL working group is working on the so-called Client Side Nullability: https://github.com/graphql/graphql-spec/pull/895

[mbonnin]

So that you could define error boundaries on the client without changing the schema

[mbonnin]

{
  # if an error happens in this field, it will become null and will not take down nonNullField2
  nonNullField1? {
    ...
  }
  nonNullField2 {
    ...
  }
}

[Stylianos Gakis]

Alright I am glad I got it all right at least 😅
Would this basically be the flipped version of @nonnull annotation? Instead of asserting something as non-null, we’d assert it as nullable.
It might be a bit awkward to have one look like an annotation and the other have a question mark, but I guess it’s still a WIP so those questions can come later. Is there an ETA on this, or is it still being discussed?
And as a complete side-note, I tried typing out the @nonnull annotation now somewhere, and I think that AS/IntelliJ don’t recognize it.
Also found this issue. Would this act as a “global @nonnull” sort of? In order to avoid having to define it in all places where that field is queried?

[mbonnin]

flipped version of @nonnull annotation?

Yep

It might be a bit awkward to have one look like an annotation and the other have a question mark,

The RFC also allows ! instead of @nonnull

{
   # same as nullableField @nonnull
   nullableField!
}

Is there an ETA on this, or is it still being discussed

Discussions in the working group take a loooong time before they're in the spec but that doesn't prevent us from implementing it. The RFC has made a bunch of progress already

AS/IntelliJ don’t recognize it.

Indeed, it's not standard so that's another reason we should work on an IntelliJ plugin. We're starting to think about it. Hopefully we can do something in 2022 🤞

Would this act as a “global @nonnull” sort of?

Exactly! Which is my prefered solution at the moment. Making it in each query is flexible but a bit verbose IMO

[Stylianos Gakis]

! and ? instead would be awesome! They line up with what we’re used to in Kotlin almost perfectly as well, which is a nice side-effect 😄

IntelliJ plugin

The existing one is in my experience working perfectly for my needs, so if it’s just for small changes like that I’d hope you can just fork it and go from there. Much less work that way.

my prefered solution at the moment

But it’s not implemented yet right? I see the issue is still open, so probably haven’t had the chance to do it yet.

With all that said however, then at the very moment, before the client site nullability is implemented, there’s no other alternative other than changing the schema itself right? If that’s the case I guess we can’t really use partial responses as changing the schema would mean the iOS and web clients will also be affected and I don’t think they’d appreciate that.

Would a workaround be to use the existing downloadSchemaFromIntrospection Gradle task and manually change the types that we’d want to be nullable so that they only affect our client? Kinda like how we edited the schema in this discussion. Then the generate gradle task should generate them as nullable, and this wouldn’t change what the other clients are seeing.

[mbonnin]

But it’s not implemented yet right?

Right

With all that said however, then at the very moment, before the client site nullability is implemented, there’s no other alternative other than changing the schema itself right?

Right

Would a workaround be to use the existing downloadSchemaFromIntrospection Gradle task and manually change the types that we’d want to be nullable so that they only affect our client?

I think that'd work