Data Engine Caching (WORK IN PROGRESS)

[amcgee]

Just putting this here to keep track of it, copied from a Slack discussion. To be extended to a full spec.

---

There are basically 3 caching layers that we’ll have to tackle independently:

1. Initially it will just be a de-duplication model, to prevent fetching of identical data by different components on the same page during a very small window of time (100ms, say). This isn’t technically caching, but should reduce network overhead a lot and allow data dependencies to live closer to where they are used (within a component in a library, for instance). A good starting point for this would be Dataloader, but there are some interesting problems around normalization and de-duplication within our API schema.

2. Second would be single-session application caching, which would persist objects in memory to prevent duplicate requests from causing duplicate network round-trips (if the URLs are slightly different or different fields are requested, for instance, this could easily miss the browser cache and we often see this in practice in our apps). We’ll need to be very careful in how we design that to ensure we’re covering all use cases and not showing stale data - it’s not fully designed yet.

3. The final piece would be “offline” caching, using a local storage mechanism and/or a serviceworker to support cross-session and even cross-application data sharing. This again will need to be very carefully designed, and some things we will want to explicitly never cache. This would probably involve a TTL, possibly with a mechanism to check staleness of items in the cache with a lightweight request to the server or even a websocket. I see this as the hardest of the three, but if we get it right it could be very powerful. We will lean on the experience of the tracker team's experience with the capture apps (which do metadata caching) and improve on things like cache invalidation and background updates.

---

Data security concerns for long-term caching
For long-term caching (# 3 above) we need to consider the security of data at rest on user devices. This may involve some kind of local encryption. The Android team has implemented this, we should coordinate with them. And this is a vaguely-related article for reference (about encrypting subscription-guarded content to prevent multiple content round-trips for lightweight mobile-first applications)