Parity with Kotlin SDK for cache chaining and optimistic cache updates

[postmechanical]

Use case

We have the need on iOS to support in-memory and SQLite caches and potentially N SQLite caches in the future given the volume and structure of our data. We also have the need to optimistically update the Apollo client cache in offline cases. While both are presently possible on iOS via a custom NormalizedCache implementation that wraps the in-memory and SQLite caches and via additional local cache mutation queries and models, doing so requires implementing significant extra code for iOS only in our apps that is tightly coupled to Apollo implementation specifics. Lack of parity between the two SDKs is problematic in this specific regard because more code is required to achieve the same result on iOS as Android, the iOS binary size is proportionally increased, and friction results within teams working on features for both Android and iOS when using SDKs with disparate and divergent features and functionality.

Describe the solution you'd like

The Kotlin SDK provides a simple and clean API for chaining caches and optimistically updating the cache without requiring additional queries and models. Please update the Swift SDK to match the Kotlin SDK in this regard.

[AnthonyMDev]

Thanks for the feedback @postmechanical. A spilt cache implementation is definitely something we want to do, but with full transparency, we have a lot of higher priority work to do, and it's unlikely that we allocate engineer resources to building that any time soon. There is actually already a (very long standing) issue to track this request #1467. Wrapping the NormalizedCache to allow for the split cache is totally a viable (albeit manual) solution right now. But it also give you complete control over the mechanisms for splitting and merging cache data. Any APIs we build to make this easier are going to need to be really well thought out and require some significant work.

That said, Apollo iOS is an open source project, and we are always happy to work with external contributors. If you or anyone on your team are interested in working on building a feature like this and contributing back to the repo, we are always willing to allocate the time and resources to guiding the API design, doing code review, and getting new community-led features shipped!

---

As for the local cache mutations, we have heard that feedback a lot and there is an item on our roadmap to make this easier (linked issue #3246). We are working on a few other things right now, but this is something we have committed to working on in the coming months, so stay tuned!

---

We appreciate the feedback, but as there are already issues to track both of these requests, I'm going to close this issue as a duplicate. Feel free to continue the dialog here or in any of the linked issues though!

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.