Caching GraphQL Responses with Core Data

updated over 1 year ago; latest suggestion over 1 year ago

This proposal has been withdrawn...

Core Data is a powerful tool for persisting structured data in iOS applications. Can this same technology be leveraged to store an unstructured graph of data? This talk will explore how we can efficiently cache data from any GraphQL API to reduce data latency and improve user experiences in mobile apps.

The talk will focus on 3 main questions:

How can we define a Core Data schema that can represent responses from any GraphQL API? First, we must determine how to normalize a graph of objects into a set of unique records. Then we need to define a flexible schema that allows us to store a list of fields of unknown size and contents. Since the responses have been normalized, we also need a way to model relationships between the records to preserve the graph functionality.

How can we transform a GraphQL query into a Core Data fetch request? This requires some sort of runtime query interpreter that can take a raw GraphQL query string and transform it into a collection of identifiable records to be fetched from the cache. We then need to build a fetch request that can fetch all of these records and then build them into the JSON format that mirrors the structure of a network response.

Can we improve the performance of this solution to return cached data more quickly? This will explore how to profile Core Data using the flag and Xcode Instruments. We will then go over a few techniques that can be used to improve the efficiency of the fetch requests so that we spend the minimum time possible waiting for the database.

Hopefully by the end of it you'll have learned something new about Core Data and GraphQL that you can apply to your own software!


  • 8b2f2d3e6553c2b4048b93300959895ab76b4154?size=100x100 8b2f2d3e6553c2b4048b93300959895ab76b4154 suggests over 1 year ago

    This sounds interesting, but it also sounds like there's a lot to cover in 30 minutes. Especially the CoreData profiling in part 3. I think that could easily be a whole talk itself.

    On the other hand, one reason I've always resisted GraphQL is because I'd have to figure out some caching implementation.