Context

Apollo Client for iOS is behaving unexpectedly. Specifically the caching. If a query errors out and returns null, the iOS side still caches the response.

Imagine a query, movieTimes that depends on an external service. If that external service fails for reasons beyond our control, the movieTimes response will be null. When that null value is cached, any subsequent movieTimes queries will result in null, even if the service has started working again.

Possible solutions

1) Make movieTimes non-nullable. In the event the external service errors out, the null value will bubble up the response tree to the data object, return data null. This works, but it wipes out any other queries that might have held useful data.

2) Cache nothing. This would hurt performance.

3) Modify the server to only share responses for paths that don’t cause errors. This is a deviation from GraphQL standards which treat the incoming request as a contract for the data that will be returned to the client. It might be possible to do using directives

Hiding a null response to prevent it from being cached?

Does this conflict w/ the GraphQL spec?

From client-specified queries in Overview:

Client‐specified queries: Through its type system, a GraphQL server publishes the capabilities that its clients are allowed to consume. It is the client that is responsible for specifying exactly how it will consume those published capabilities. These queries are specified at field‐level granularity. In the majority of client‐server applications written without GraphQL, the server determines the data returned in its various scripted endpoints. A GraphQL query, on the other hand, returns exactly what a client asks for and no more.

The question after that blurb is, ‘But can it return less?’

From 7. Response

A response may contain both a partial response as well as encountered errors in the case that a field error occurred on a field which was replaced with null.

Our Conclusion

The Apollo iOS SDK should not cache anything when any error is returned, like in the React SDK . Unfortunately, the iOS SDK appears to be a second class citizen to the React one. We will go with option 1. All root types are non nullable, so in the event of an error, the entire data object will be null, which hamstrings one of the GQL perks. The next step would be to fork the Apollo iOS SDK and fix the caching behavior.