[Suggestion] Offline-First Application

[morrys]

Hi all,
I wanted to propose to integrate my library into your project https://github.com/morrys/wora/tree/master/packages/apollo-offline

I think that in a chat it is very important to be able to look at messages and send new ones even if the internet connection is absent.

I also have a version for Relay Modern: https://github.com/morrys/react-relay-offline

I am available to carry out and / or help with integration.

I await your opinion about it,
thank you

Lorenzo

[Urigo]

@morrys that is awesome!

First step - how and where do you think we should integrate it into the script of the WhatsApp clone?

We have the chapter about caching with Apollo client here: https://www.tortilla.academy/Urigo/WhatsApp-Clone-Tutorial/master/next/step/7

Then mutations here: https://www.tortilla.academy/Urigo/WhatsApp-Clone-Tutorial/master/next/step/8

Live updates with subscriptions here: https://www.tortilla.academy/Urigo/WhatsApp-Clone-Tutorial/master/next/step/10

And adding and removing chats here: https://www.tortilla.academy/Urigo/WhatsApp-Clone-Tutorial/master/next/step/12

Do you think it's worth a separate chapter? my tendency says yes but maybe you think it's better to integrate into an existing one?

My first thought is putting after all of those chapters I've mentioned above to demonstrate offline handling for all of those actions.

Let's start with a doc where we write the rough script for that chapter.
You can add it here: https://docs.google.com/document/d/1p2Zio6Js2eoFfHs9CjIMF6jTuNyD4eQEHlgEAKhAqM8/edit
or in another doc of your choice

[morrys]

I also think that a separate chapter is better so you can highlight all the changes necessary to manage offline

[wtrocki]

@morrys There are lots of approaches to the offline problem. Can you explain how morrys/apollo-offline resolving this issue? I have reviewed your code and really like it, but there are some parts of the code that I do not understand fully and I see a couple of problems that we have encountered and resolved in different packages before. Things like optimistic response id mapping, multiple edits on the same mutation or subscription.

Do you have some more info about this project is resolving offline problem?
Are you willing to collaborate on this topic?

encryption?: boolean; not yet implemented in @wora/cache-persist

We have that done for apollo-cache-persist so you can reuse some of the code.

I will be really excited to collaborate with you to build a fully functional offline library. I'm the maintainer of Apollo Cache Persist and I would love to bring some of your ideas directly into apollo cache persist.

I'm one of the authors of https://github.com/aerogear/offix (we have been apollo-offline before but we needed to rename because we did not get permission to use Apollo name). We are working on offix for more than a year and still exploring the challenges of offline and data replication. The biggest challenge for us was actually to stay up to date with Apollo. Version 3.0 that is coming soon is also going to break a lot of stuff for the caching layer. I really like that you are swapping Apollo Cache and I would like to apply some of the patterns you have employed to offix.

As for the original issue, I think we can approach offline problem in many ways here:

• State management problem
• Network management problem
• Operation replication problem

I personally think that state management problem is the most important here - users can simply use local state to save some data and replicate that to a server when ready. This is where https://github.com/kamilkisiela/loona can play some role.

I think instead of talking here what package we should be using we can focus on the what approach for offline we want to present for a wider audience that might look for some generic cases. In many cases, offline can mean Query caching and state management. Persistent mutations have so many side issues and bugs that for some community members we were advising against using offix and instead follow up lightweight RetryLink based https://github.com/carvajalconsultants/apollo-link-offline

[wtrocki]

See discussion on https://github.com/benseitz/apollo-link-offline/issues/1

[morrys]

Hi @wtrocki, nice to meet you.

a small premise is due, no library can completely solve offline problem. The main objective of @wora/offline-first, @wora/apollo-offline and react-relay-offline is to give all possible facilities to those who need/want to face this challenge.

The second goal is to help integrate new functionality or extend the configurability of the relay and apollo libraries. This is to ensure greater stability of the library and focus exclusively on issues related to the offline.

Collaborating is the real strength of open source :) (Https://github.com/apollographql/apollo-feature-requests/issues/154)

I kindly ask you to open the issues on my repository as it is a discussion involving more than one package.

[wtrocki]

From my point of view using wora or any other offline lib in whatsapp clone will be overkill and lead to a different architecture than the messaging app will need. Usually, graphql messaging apps will need to have some logic to monitor subscription connection and then enqueue messages in the local state. Then users can manually trigger to resend them or have a periodical check to send them again.
This is very simple to resolve on on app-level and introducing the library can lead to couple of corner cases and additional logic required to listen to failures and populate them back to users.

Network state checks here are not reliable as we might have a network but not being able to push messages at all (very common problem for messaging apps). I was personally hoping to extend What's Up clone to get offline cases and IMHO the best way to do so is to do it without any library apart from Apollo-Cache-Persist. I have implemented GraphQL messaging app before and what really worked for me was NetworkState aware subscription feature we thinking to add in next release of the offix.

I'm happy to add offline support to what'sup clone but I would hope to use just state library and Apollo cache. Version 3.0 will shake things up so we can avoid doing a lots of work that will deprecate so fast and introduce many breaking changes in tutorial.

This way we get:

• Hook into the existing Apollo ecosystem and use the most of it.
• Use existing state management from apollo client or Loona.
• easy to support - which for me is the main pain point - things break a lot.
• simplicity for users - no need to deal with some external stuff they do not know and it is bugs
• compatibility with Apollo 3.0 (we are working on cache rewrite for that and there is big chance that many problems including offline support will be resolved by Apollo itself in 3.0

I will be hoping to have something that makes Whatapp clone simple and maintainable over the time.

Messages (optimistic responses) will disappear after restart of the application (in offix we have some workarounds for that, however, if we separate local state from the network cache we can get that seamlessly without any library.
We can simply do @client queries along with network ones that will rely on cache and have both results displayed in the app.

[Urigo]

Hi again,

first let me say I'm really happy about this discussion - This is exactly the reason I've created this clone!
So we can have people from the community collaborate and demonstrate they solution in a place where it is easy to show the difference side by side.
So thank you for doing this here!

First some general comments on the purpose of the clone:
The goal of the WhatsApp clone is not to have a simplistic tutorial but as comprehensive and deep dive as possible.
If that means to add more advance features to the clone that's a good thing I am happy to do!
I am dedicated to maintain this tutorial for the long term and I don't mind if it's less simplistic, exactly the other way around.

That means that it's true that there are the messaging offline capabilities but I don't want to settle with just those - I want to add more features to the WhatsApp that cover also other, more advance use cases.

Some thoughts about Apollo 3.0:

• I have no idea when it is going to be out and I don't see good communication from them about what's going to happen there
• We have a plan to also create a Relay version of the WhatsApp clone and show a deep comparison that lives on and keeps updating as those libraries change

For those reasons my first priority is to have as many use cases and features on the clone as possible.
That way we can show how each of those use cases work on Apollo Client 2, 3 and on Relay.
That way we can have the best comparison between the different solutions.

So that's where I need to help first.

I've created a public doc on GDocs where we can list all of the libraries, use cases and features we can think of.
Once we'll have all of those the conversation will be a lot easier as we can demonstrate each use case as a feature on the clone, implemented with each library, to choose the best one and to show where we lack and need better solutions.

Please help me and let's collaborate on this: https://docs.google.com/document/d/1AEv6fwrl3tDMN3-o_WMFGjnBFmaDRTocg0JXGm5gxJg/edit

[wtrocki]

After reading all the details I think we can collab together with @morrys to add offline support and conflict resolution to whatsapp clone

[morrys]

Hi everyone,
I looked at the project and I must say that it is well prepared to manage the offline.

Even the management of possible conflicts is very limited.

A theme that will be very interesting instead will be the subscription.

Saturday I will dedicate it to the document but in my opinion it is better to avoid listing all the problems and theories on the offline but to proceed with explaining the first necessary step and during its realization we will highlight some problems that we will face in the next step.

This will lead us to evolve the tutorial gradually and put the conditions of people to understand both the problem and its resolution.

[wtrocki]

Saturday I will dedicate it to the document but in my opinion, it is better to avoid listing all the problems and theories on the offline but to proceed with explaining the first necessary step and during its realization, we will highlight some problems that we will face in the next step.

This is really good suggestion that really basing on my previous post. I wanted to start with something that will not overload people with too many offline concepts and features. Having PR with something opens conversation - let's work together on this.

[morrys]

@Urigo Hi everyone,
in these days I have been busy with docusaurus and soon I will go on vacation :)

Today I decided to fork the two repositories and create the first version of whatsapp offline.

This is commit sufficient to make the application offline

This is the commit to generate client side IDs, I also added the optimistic response to the chat cancellation.

This commit in the server to manage the IDs sent by the client.

Surely the service worker needs to be accommodated for a better offline experience.

As you can see, it took only a few modifications, let me know your opinion.

Lorenzo

[Urigo]

@morrys that's amazing! thank you so much!
Maybe next thing would be to see where should we add those actions to the script?