Normalized Cache per Fragment

[oliveeyay]

Hey everyone,

I was wondering if a normalized cache per GraphQL fragment was considered before? From what I've seen the normalized cache is working at the query level today. Correct me if I'm wrong!

I'm just exploring GraphQL at the moment (worked on REST and Falcor apps before). For applications that need to be performant (poor network connectivity etc...), sharing fragments' cache between queries could be a key improvement.

Example: If we take the Github example in samples, this would translate into:

• RepositoryFragment is shared between the GithubRepositories and GithubRepositoryDetail queries
• When executing a GithubRepositoryDetail, if the corresponding RepositoryFragment is already in cache, it does not request it from the network and just adds it to the response from the cache

Context on why I'm thinking about this: In a current app architecture using Falcor, we request for paths that resolves to what we call leafs. The logic is to:

• Go through our cache for each path
• If it's resolved, the leaf is added to the response object
• If it's not resolved, we add it to a list of missing path
• We request all missing paths from network and merge it with the cache to respond to the UI

It allows us to share leafs between screens (even between lists showing only "summary" and "detail" page if I compare to the Github example). This allows for network savings and progressive loadings.

What do you think about applying the same logic to Apollo-Android? Any pros and cons that would popup immediately?

Probably some big changes around codegen and runtime, especially if it was a new cache mode?

Thank you :)