Relay: [modern] RFC cache/offline plugin

Created on 21 Jun 2017 · 13Comments · Source: facebook/relay

Hi All

RFC Cache/offline plugin

Seeking community feedback, comments and requests for an ongoing project aiming to build an enterprise cache engine plugin for Relay

This project is sponsored by Entria, https://github.com/entria

Why?

We run multiple Apps using Relay + GraphQL. We need to properly support our users when they are offline. Offline means a number of challenging scenarios that our customers face: Airplane mode, bad internet connection, no more pre-paid credit.

Currently Relay based apps don't perform nicely when our customer are offline, we also need to handle user actions while the app is in offline state. Simple use case will is:

Use case

If a user creates a comment while offline this new comment needs to shown to the user as expected. (as if the app was fully connected to the backend). When the user is back online this comment (ie. mutation) needs to be delivered to the server.

Initial list of requirements

[ ] Relay compatible
[ ] GraphQL backend
[ ] Needs to be able to store mutations created in the device and push them to the server once the device is back online
[ ] Reconciliation engine that will use a set of rules to decide how to reconcile data with server
[ ] Cache engine
[ ] Cache Eviction rules

Please note that eventually this will become a dedicated repo with a proper list of issues and milestones. For now opening this in the main Relay repo in order to increase awareness and request for comments

Source

rturk

👍21 🎉10

Most helpful comment

Hi all,
i have created this repository https://github.com/morrys/react-relay-offline thats is an extension of Relay Modern 3.0.0 for offline capabilities.
It is a first version and surely there will be improvements, fixes and refactoring to be carried out. It would be interesting to integrate it natively in Relay version 4.0.0.

To try it out: https://github.com/morrys/relay-examples.

morrys on 29 Apr 2019

👍9

All 13 comments

Sounds exciting!

Most of the pieces necessary for doing this exist within Relay Modern. It would be great it you coordinated with the Relay team as you work on this. The team is already working on efforts to use cache layers in the Relay network and Relay store.

leebyron on 23 Jun 2017

@leebyron that's the ideia, use Relay Modern framework.

rturk on 24 Jun 2017

@leebyron is there somewhere where I could find out more about the efforts from the core team? It seems that the roadmap and weekly meeting notes haven't been updated for quite some time.

hannesj on 5 Jul 2017

Messaging folks directly or mentioning them here with questions is the best bet right now - @yuzhi and @kassens are both active. Perhaps we can start writing meeting notes again, that was something @wincent had helped out quite a bit with in the past.

leebyron on 5 Jul 2017

@hannesj eager to hear your thoughts, requests and concerns.

rturk on 5 Jul 2017

My thought was to be able to better understand how the roadmap for caching in Relay modern looks like.

We have been developing an application framework using Relay classic and now thinking about technology choices for an extension. We have been happy with Relay classic, except for the developer experience, which makes it hard to onboard new devs and for the performance which degrades when the amount of data grows. As per my understanding Relay modern solves both of these problems but loses some of the functionality, such as the normalized caching. We are using the normalized cache to keep the application state in sync when showing the same data in two views in parallel (eg on a map and in a list). Of course this could be solved by using subscriptions instead, but we don't yet have a backend system capable of handling those. So, my question would be is this something you are thinking of supporting in the future or should we just concentrate in developing our back-end and a custom network layer in order to be able to handle subscriptions and improved caching for switching between views.

hannesj on 6 Jul 2017

cc @JenniferWang

yuzhi on 6 Jul 2017

This is really a big question and I don't have a conclusion. My intuition is to keep the (framework-level) cache as simple as the same normalized store as in the memory.

Reconciliation engine that will use a set of rules to decide how to reconcile data with server

This is something hard for me to imagine. The common practice for GraphQL is co-locating data requirement with the view, which is an optimization for on-line mode but not offline, especially with the side-effects from mutation. This nature might suggest there is no good way to reconcile the local (cached) data with the server. You might end up discarding local data anyway.

Needs to be able to store mutations created in the device and push them to the server once the device is back online

I think this step might better be done at product level not the framework level. It is hard for Relay to answer "Should we cancel the following queued mutations because an earlier one fails on the server?" Also what if the optimistic response you provide does not match the actual server response? Do we still want to execute the later mutations? If we need to wait for each queued mutation to be resolved one-by-one, will it take too long?

JenniferWang on 14 Jul 2017

The biggest offline problem is syncing. There is no silver bullet. Well, I lied. The key is immutability. Syncing across online and offline devices means a lot of versions aka older came later for new checks. I don't know yours use case, but the ability to edit documents while offline opens a lot of hard to solve easily issues. Do not delete, make long lasting versions when offline is involved. And try to avoid offline editing as much as possible.

steida on 27 Jul 2017

👍1

@steida
I think as a starter, simple read-only caching for offline use would be good enough.
For my use case, Each user will have a long list of contacts that should be cached offline.
When online, users can read / edit them.
When offline, users should be able to read them without editing abilities.