I was reading about the <@nonnull> directive here ...

# apollo-kotlin

[Stylianos Gakis]

I was reading about the @nonnull directive here and I was wondering, is there also room for a @null directive?
We have a field which was wrongly marked as non-null on the schema, but really it should just be null for various reasons. One way is to deprecate that one and add a second one, and keep the old one around for old clients so that we make a forwards compatible change. That works fine.
I was thinking could we go the other way around, and mark it as nullable on our clients for now, in preparation for the future. Then in X time forward, we can go and make the breaking change in the backend, turning it nullable, and by that time we will make sure that we have kill-switched all old clients, something we do anyway on some intervals for other reasons which are unrelated to this, but would help in scenarios like this.
I can for now go on and edit the final result of the ApolloDownloadSchemaTask task, which would work too, but I am just curious if there was any previous discussion on this idea in general that I would find interesting to read.

[mbonnin]

was wrongly marked as non-null on the schema

That's interesting, it's usually the other way around!

[mbonnin]

could we go the other way around, and mark it as nullable on our clients for now, in preparation for the future

Looks like that would work.

[mbonnin]

I can for now go on and edit the final result of the ApolloDownloadSchemaTask task

I would do that in the short term. You can even automate this with some Gradle

[mbonnin]

There is a whole GraphQL sub-working group dedicated to nullability if you want to do further reading: https://github.com/graphql/nullability-wg

[mbonnin]

Currently the focus is on the symmetrical problem to yours but this is also an interesting one.

[mbonnin]

I guess the main question is observability. Maybe in your org you know when all clients have made the switch but in larger orgs, it's usually very hard to tell (which is where Apollo prodcuts help)

[mbonnin]

So we'll need something in the query that can be observed from the backend, which you don't have if you're editing the query manually

[mbonnin]

Feel free to put your name in the next meeting agenda if you want to discuss this further

[Stylianos Gakis]

I would do that in the short term. You can even automate this with some Gradle

Yeap, I got this task https://github.com/HedvigInsurance/android/blob/6092dc0c00eec31c8fb0b12661e7b99ffe[…]uild-logic/convention/src/main/kotlin/ApolloConventionPlugin.kt locked and loaded for such scenarios. I added it with your help quite some time ago. I may just put it there indeed.

… but in larger orgs …

That is indeed true. Normally I would simply suggest the normal cycle of deprecation which I described above. That’s fool-proof, and then through using our metrics from apollo-studio we could easily determine when the right time for us to remove the deprecated field is. I was only thinking this here because we know who are 2 clients are, this is a very rarely used field, and I was also just being curious 😄

There is a whole GraphQL sub-working group dedicated to nullability

Very interesting, thanks for sharing it. I think it’s not a very strong need that we have, and honestly in almost all scenarios doing that as a means to migrating away from the non-null field would more or less be strictly worse (besides less code) from the method I describe above. So if that would be the only use case I honestly don’t think I would push at all for something like it to be added.

Again, mostly curiosity made me ask this 😄

[mbonnin]

Something else you might find interesting is https://github.com/xuorig/chromatophore. It didn't get much traction but I think it would solve your issue

[mbonnin]

The tldr; is there is some client <-> server negociation when downloading the schema so that "new" enough client can signal they have support for "stuff" (sorry that's a bit vague, it's been a while I haven't been there)

[Stylianos Gakis]

Heh, interesting idea. Don’t let the clients pay for the backend sins 😅