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.

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)

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 …

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

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 …

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

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

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

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 …

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

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?