Graphql-engine: RFC: Guide to offline-first and realtime sync with Hasura

Created on 25 Mar 2020  路  9Comments  路  Source: hasura/graphql-engine

We have a tutorial for building an offline first app with RxDB & Hasura at https://hasura.io/blog/building-an-offline-first-web-app-with-rxdb-hasura/

There is also a design guide (WIP) at: https://hasura.io/blog/p/1c5079be-d19e-4fd4-b700-2a6181f3fc40/

Demos:
Todo App: https://rxdb-hasura-demo.netlify.com/
Trello: https://trello-offline-first.netlify.com/

Todo:
For our RxDB tutorial, we're looking at adding a guide and best practices around:

  1. Error handling: Patterns to detect sync errors and propagate that to the user
  2. How to handle initial loading of a large amount of data
  3. Showcase conflict resolution with Hasura (one with postgres, and one with actions)
  4. Handle data modeling on RxDB (realtional vs nosql).

There is also https://github.com/pubkey/rxdb/issues/2048 that needs to be fixed.

What else would you like to see from an offline first & realtime sync perspective? Comments appreciated! 馃檹

rfc

Most helpful comment

Just an idea, but I think It would be super cool if you build a data store (just like Amplify Datastore) that works out of the box with Hasura.
The ideal DX would be like, I take care of changing data locally according to my business logic, and Hasura Datastore takes care of replication and conflict resolution

All 9 comments

I think this is great!

The more we can encourage offline-first the better. There is a real opportunity for Hasura to lead here for the GraphQL community.

It would be amazing to have a very barebones example as well without the dependency on RXDB.

Maybe modify the Todo app for other frameworks like Vue, Angular.

I know there was a mention of some example apps being created. Would be great to some an offline-first ones.

Just an idea, but I think It would be super cool if you build a data store (just like Amplify Datastore) that works out of the box with Hasura.
The ideal DX would be like, I take care of changing data locally according to my business logic, and Hasura Datastore takes care of replication and conflict resolution

There is now a guide focusing on conflict resolution over here: https://hasura.io/blog/couchdb-style-conflict-resolution-rxdb-hasura/

@gautambt 404 link

Oops! I have updated the comment above with the right link! Thanks, @weyert @macs91

Should have an example with flutter or native Android, maybe a generic way to do that.

I am in the last days of developing an offline-first app based on the ideas in https://hasura.io/blog/couchdb-style-conflict-resolution-rxdb-hasura. I used to work with CouchDB itself before moving to PostgreSQL because of it's relations, role-management and general greatness. Before reading the article I hadn't realized you could solve conflicts CouchDB-style with PostgreSQL. Thanks _a lot_ for that article.

The app is here: https://github.com/barbalex/vermehrung

Instead of RxDB it uses Mobx-State-Tree which is an awesome tool for the task. Together with mst-gql. I _love_ this combination. You should try it too 馃槆.

Instead of resolving conflicts on server _and_ client it only resolves them on the server. The client reads winners and writes revisions. This solves the problem of the client having to have all revisions - blowing up storage space and network traffic.

The server adds a list of conflicts to the winning revision. The client then loads those revisions when the user resolves the conflict.

Would love to see a guide.

I would love to see a focus on the devops side as well, managing dev/staging/prod environments, migrations, docker-compose-ing, best practices etc.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tirumaraiselvan picture tirumaraiselvan  路  3Comments

coco98 picture coco98  路  3Comments

bogdansoare picture bogdansoare  路  3Comments

egislook picture egislook  路  3Comments

anisjonischkeit picture anisjonischkeit  路  3Comments