Apollo-feature-requests: How to achieve offline support?

[Bessonov]

Migrated from: apollographql/apollo-client#424
and
Migrated from: apollographql/apollo-client#2460
and
https://github.com/apollographql/apollo-client/issues/307

Please vote with :+1:, if this feature request important for you.

[Bessonov]

Hey, @jbaxleyiii, you've marked https://github.com/apollographql/apollo-client/issues/2460 as "high-priority". Is there any progress on this?

[Bessonov]

Related https://github.com/apollographql/apollo-link/issues/125

[Bessonov]

Good answer to the question what offline support means: https://github.com/apollographql/apollo-client/issues/424#issuecomment-233731705 . Next answers provide some examples of syncing DBs like PouchDB/CouchDB and minimongo/MongoDB in Meteor.

Other syncing solutions: https://github.com/prismagraphql/prisma/issues/1659#issuecomment-391129297 and https://github.com/orbitjs/orbit

[jamesreggio]

Here's a comment I wrote about how you can cobble together pretty decent offline support with packages that are already available today: https://github.com/benseitz/apollo-link-offline/issues/1#issuecomment-371678922

[Bessonov]

From @chrisfosterelli / https://github.com/benseitz/apollo-link-offline/issues/1#issuecomment-436421802

We spent some time building our application for full offline with React Apollo's new and components. We got offline mutations to persist across refreshes using a wrapper around the default Mutation component.

In case it's useful to anyone else, we wrote about how we got that to work in detail here: https://medium.com/twostoryrobot/a-recipe-for-offline-support-in-react-apollo-571ad7e6f7f4

[sebas5384]

We are working on this lib to get granular offline support (still wip):
https://github.com/TallerWebSolutions/apollo-cache-instorage

[morrys]

Hi everyone,
these days I created these libraries to manage both cache persistence and offline support:

https://github.com/morrys/wora/tree/master/packages/apollo-offline

https://github.com/morrys/wora/tree/master/packages/apollo-cache

They are projects born by extracting the logics of the offline support from:

https://github.com/morrys/react-relay-offline

You can find a first example project here:

https://github.com/morrys/offline-examples

A very important feature is the integration of the offline engine within the client logic and not at the network level.

Your opinions on both libraries are welcome.

For more information contact me on twitter: https://twitter.com/m0rrys

Thank you,
Lorenzo

[wtrocki]

The alternative will be to use https://github.com/aerogear/offix/

It supports offline persistence, subscriptions, data encryption and conflict resolution.

[loganpowell]

@wtrocki offix lookin' pretty sweet

[mbret]

Offix officially stated they would move away from apollo and not support the v3. I guess we are still in need of some offline features from apollo framework then.

[TeNNoX]

Offix officially stated they would move away from apollo and not support the v3.

I think that's not fully accurate: https://github.com/aerogear/offix/issues/543#issuecomment-688418858

[wtrocki]

TL;DR - Offix got feedback from the community that:

• Offline read is the most anticipated feature
• Offline writes are usually only for some small parts of the app.
• If the app needs to be fully offline using the existing Apollo API to deliver offline is challenging as it wasn't designed to cover this case

We are doing an offline database solution rather than just adding an offline layer on top of the Apollo.

Status of offline support for Apollo

There are 4 levels of offline support right now

1) InMemoryCache (will keep things cached until website/app is restarted)

Supported by Apollo. CacheRedirects giving developers some form of customization for advanced use cases

2) ApolloCachePersist (persist cache and restores it on startup)

Offline without write access - supported by Apollo Community (good work from @wodCZ who recently fixed dozens of bugs)

3) Community extensions for supporting offline writes

Wora library done by @morrys seems to be the most popular choice. Challenges of those solutions
were that we were relying on some internal Apollo Client API that might change etc. and general experience is still not the best as offline applications behave differently even when online etc.
Offix community usually wanted to have offline capabilities only for some small chunks of schema etc.
This type of library was proven to be really hard to maintain for Offix so we moved to level 4

4) Realtime Database

This one uses GraphQL as transport and uses an offline database (think Firebase, AppSync, etc.)
This is the path we trying to with the https://offix.dev and hope that we can provide something that will complement level 1 and 2, while avoiding maintenance hell and complexity of level 3.

The benefits of those is that you can use Apollo client on level 1 and enable database only for the elements of the system that really needs to be fully offline etc. This approach was proven to be successful for folks that wanted to have a flexible and stable solution.

Initially, we build this on the backend using our own implementation: https://graphback.dev/docs/datasync/intro but we are also investigating using Apache Kafka

I hope that at some point the Apollo team would take over and offer level 2 along with level 1 as this is the most requested feature IMHO.

[mbret]

After playing for couple of month with Apollo trying to achieve an offline first app I decided to drop it as I was facing more and more challenge every day while having a very fragile and gigantic code base just to deal with it. This one is probably on me tho, I should have understand better what is apollo designed for before picking it.

I completely switched to rxjs and I was able to reduce my code base by about 60% for the same features.

@wtrocki I wish you the best with your new offix and I will certainly follow your work. Offline world is truly a challenging one.