Hey guys, I have a question regarding requesting non-existing fields. Currently when I ask for a fie...

# graphql-kotlin

[Martin Brehovsky]

Hey guys, I have a question regarding requesting non-existing fields. Currently when I ask for a field which does not exist in the schema, the whole query fails, but I wonder if it would be somehow possible to return the other fields which are valid and return errors (in the errors field) only for the fields which do not exists in the schema.

[Lenny]

That’s counter to the graphql spec, so it’s super unlikely to be supported in graphql-Java (which powers graphql-kotlin under the hood)

[Martin Brehovsky]

Yeah, I realize that, but I’m wondering if there is a way to do it by supplying some sort of missing property resolver which would allow me to experiment with this …

[Dariusz Kuc]

one of the key benefits of graphql is that it is strongly typed so i dont think this use case will be supported

[Dariusz Kuc]

queries are first parsed and validated so I guess you would need to implement your own validation logic to ensure that it doesn’t blow up on unknown fields

[Dariusz Kuc]

since its internal to how graphql java processes stuff i guess you would need to re-implement execution logic

[Dariusz Kuc]

personally I’d advise against it as it is anti pattern

[Martin Brehovsky]

I see … yeah I realize it might be antipattern, but in the real world we might be in a situation when the schema served by the server might be out of sync with the schema expected by the client (e.g. serious operational rollback, the clients in the field expect a newer schema), so I was wondering if there is mechanism how to fail gracefully in those cases …

[Dariusz Kuc]

in general, i’d recommend to try to avoid such situations and have a build pipeline that verifies that your schema changes are not breaking any clients

[Dariusz Kuc]

you could get this functionality through Apollo (paid) or potentially through https://graphql-inspector.com/ (but you would still need to have some mechanism to verify if any of your production clients are affected by the changes)

[Martin Brehovsky]

the problem is not forward updates, the problem is operational rollbacks which might occasionally force the schema version to be reverted …

[Shane Myrick]

If you always are fixing with backwards compatible changes then rollbacks will still work, unless you eagerly remove fields before some rollback period is passed.

This issue wouldn’t go away with any other API system, this is more getting into how do you communicate API changes between client and server teams, and what is the expectation for support on deprecated or unused fields/endpoints

[Martin Brehovsky]

Well operational rollback usually means you return to your previous version. So if you add a new field to your schema, deploy, this is a compatible change. However if you rollback this schema to the previous version (remove the field), this is a breaking change.

You are right, the same problem exists with other APIs, but for example when we take REST, it is way more finegrained, and typically you can write your client code defensively to “adapt” those failures - e.g. missing field in the REST response, no big deal as mostly you can replace it with gracefully degrading defaults on the client side.

The problem with GraphQL in this case if your query might be spanning across multiple business domains as this is how it maps to the UI. With the REST calls, typically this would require multiple REST calls and if one of them would fail, you can still gracefully degrade the experience. However with GraphQL query (and out-of-sync incompatible schema), the whole screen fails and there is no way you can gracefully handle this situation on the client). Therefore I though what might be a good workaround is to allow the query to still perform, but response would signal back certain fields are not available (obviously that would work only for nullable fields) … I don’t think this breaks the strongly typed contract between the client and the server, but rather adds flexibility to deal with cases like that …

[Shane Myrick]

You don't have to powered your entire screen with one API request. You can still break up the GraphQL queries

[Martin Brehovsky]

I realize that, but isn’t the benefit of graphql the ability to bring the API closer to the UI and to allow me to minimize the number of requests I need to make over the network?