A roadmap for offline-first?

[frederikhors]

I would like to know how ready I can consider this project if I have to introduce it to my colleagues to choose a solution for a React project that NECESSARILY needs to run VERY often and for SEVERAL HOURS offline.

A case of so-called offline-first.

I would not want them to choose the (usual) PouchDB/CouchDB solution, especially since I would like to reuse the same already working GraphQL backend.

This great guy wrote a great guide to choosing the right offline-first project: https://jaredforsyth.com/posts/in-search-of-a-local-first-database/.

1. How do you think we can answer for URQL today?

2. And what are the plans for the future?

Thank you.

[kitten]

Oh, it's Jared Forsyth! 😆 Yes, I remember his CRDT exploration.
On our end, what we've been thinking of is creating a large scale test app. We were thinking of a realistic notes app or other forms of apps that accumulate large amounts of data. If we can prove that Graphcache works well in these scenarios and test an actual app under our control and architecture at difficult conditions, then that gives everyone a template to work off of and a demo to see the results for themselves.

How you can answer this today is difficult; if you have an urql app in production already it'll be easy to flip to Offline and test it out for yourself. But if you don't it'll obviously not be as easy to hypothesise how well it'll do for your use-case.

[iamclaytonray]

Was this ever made?

[frederikhors]

We are evaluating URQL and REACT because we want to build a CRM-like that must have all the data and a 100% offline CRUD with synchronization once online.

I cannot understand if we can achieve this with URQL.

Some of the questions in the article:

1. Are conflicts handled? How?

2. How much data does the client need to store to fully replicate (full offline data access & editing)?

3. Does it require all data to live in memory, or can it work with mostly-persisted data? (such that large datasets are usable)

4. Does it correctly handle working on multiple tabs in the same browser session?

[JoviDeCroock]

1. We have a concept of commutativity so the order of dispatching matters, this means that even if the responses come out-of-order we'll apply them in order.
2. This is a question for your specific appliance and you will need to differentiate which data should be accessible offline and which wouldn't.
3. data-persists to your cross-session medium while using the offlineExchange but data will always be used in memory to ensure you are using it at the maximum efficiency since only using your persistent medium would make stuff slow.
4. Currently it only hydrates data when opened so the synchronization of these two isn't constant, there could be some sort of signal for that.

Point 4 has a lot of complexity where there are not many answers to, for instance how do you signal data-modifications across tabs, ...

[JohnAtFenestra]

We're investigating URQL for offline storage as well. Our use case is to allow for disconnected update of business data on a PWA when the user is in an area where online access is restricted or prohibited.

I originally investigated AppSync Client, however, over the past several months the project appears to be dead (lack of updates for several months and no replies to questions). Amplify appears to have moved to support for DynamoDB.

I started looking at URQL last week and have been very pleased so far, but am running into issues trying to test out offlineExchange which are likely due to me overlooking something obvious (issue mentioned in discussion earlier today - hoping for a reply from an offlineExchange guru).

For the record, we have a need for encryption and already have a layer in place which will permit storing the data encrypted via SubtleCrypto. That introduced an interesting issue in that we need the client to be restartable so that we can begin in a logged out state and then reinitialize the cache and mutation queue after logging in. It looks like it could work and we have the layer ready from our AppSync research.

[kitten]

Hope you're getting on fine with the Offline Support! ✨

I'd imagine that you could in theory keep two clients around, where the logged out one maybe even doesn't store offline data and is completely isolated for logged out users? Obviously I don't know what you're doing in detail and what your requirements are, but one trick is that it's possible to swap out and/or recreate the client on the fly.

[JohnAtFenestra]

"Hope you're getting on fine with the Offline Support!"
Yes! It turned out it was a bug in offlineExchange which had been addressed. I'm not sure how I got the "bad" version except I may have done an update earlier in the week. None-the-less, I'm very happy with the support and very much appreciate this communication from you.
My current plan is to recreate either offlineExchange or the entire client, with the offline exchange cache being wrapped up in a function which forwards to a recreateable delegate:

  let $reinitializableExchange
  function reinitalizeOfflineExchange() {
    console.log(
      `Reinitializing $offlineExchange. Storage unlock state is ${storage.storeIsUnlocked}`
    )
    $reinitializableExchange = offlineExchange({
      schema,
      storage,
      ...offlineSupport
    })
  }

  const cache = (...args) => {
    return $reinitializableExchange(...args)
  }
...

I'm not yet certain if reinitializing the exchange is enough or if the client is also storing cached data. I'll know Monday when I finish my tests.

[kitten]

Oh I don't think that'll necessarily be necessary 🤔 It may be entirely safe to just recreate the client with the same config. I'd test that first, since it's the simpler solution. Swapping out the internal exchange pipeline by doing this won't trigger updates across the components that are using the client.

[JohnAtFenestra]

You make a good point. Thanks!

[Svarto]

A question on this, I tried to implement this for React Native but IndexDB does not work on React Native. I saw some discussion in the previous repo on offlineExchange for graphcache - is there any working implementation for offlineExchange on React Native? With e.g. AsyncStorage?

[kitten]

We chose not to add a built-in storage implementation for React Native because there are multiple storage engines that all won't be built-in, so it's very much up to your preferences. We may still ship one in the future, but it would be a separate package I suppose.

For now, creating your own storage isn't that huge of an undertaking! The web one is rather compact: https://github.com/FormidableLabs/urql/blob/main/exchanges/graphcache/src/default-storage/index.ts

You'll mostly be interested in implementing these methods and following the TS type to get it to be compliant. The implementation may also differ if you're not interested in deleting old entries.

[Svarto]

Thanks @kitten , you are right I had a look and it doesn't look too complicated. Will give it a try when my time permits in the next few weeks and report back.