Enabling flexibility for iOS cache

Client SDKs
,
1

Hi! I am aiming to empower consumers of the iOS sdk to build their own solutions to different problems by making the local cache more flexible. A simple change to the sdk would allow developers to solve for their own custom needs and build on a great foundation.

Here is a small PR to implement the required changes:

Background

In the iOS sdk, the SQLite cache is set up nicely with dependency inversion, allowing individual components defined by protocols to be swapped out if a different implementation is needed. Specifically, the SQLiteNormalizedCache accepts protocol types so that consumers of the library can implement their own components under the hood if they choose to. There are a couple reasons one might want to do this:

  • to use a different SQLite implementation
  • to add custom functionality under the hood, like a TTL policy for rows in the cache (I am trying to do this)

The Problem

All of that is possible! …almost

The use of SQLiteDatabase protocol makes it easy to implement and inject your own implementation, with one blocking exception. The missing piece is a public initializer for DatabaseRow, a type returned by one of the methods:

func selectRawRows(forKeys keys: Set<CacheKey>) throws -> [DatabaseRow]

If I as a consumer try to implement the public SQLiteDatabase protocol, I am blocked by this method, because I cannot instantiate DatabaseRow values. The default, automatic memberwise initializer for any Swift struct is internal, meaning that consumers of a library cannot use it, and get an error if trying to instantiate:

The change in the above PR, to add an explicit public init to this struct type, is all that is needed to enable custom SQLite implementations, as the original PR from 2021 seems to have intended. This change would allow me to implement the custom TTL policy on my own Apollo cache

Is it worth this small change to enable greater flexibility for developers building with this sdk? What do you think?

2

Following up, the dev team responded super quickly and landed this PR, so flexibility described in the post will be available shortly! Thanks a bunch to the Apollo dev team for awesome responsiveness

1 Like