Offix 2.0 top level goals

[wtrocki]

Top level requirements

1. Ability to work with the local data without interacting with the cache/building GraphQL queries

2. Ability to see offline changes and being able to differentiate between change that was made offline

3. Ability to work without building Optimistic responses or relying on client cache.

4. Simplicity to work with subscriptions on the root level and populate the data back to passive views and to avoid verbose hooks API and memory leaks

5. Ability to work in a simplified data interface that is utilizing https://graphqlcrud.org capabilities

6. Support any types of data containers like Pagination container, DataSync container etc.

7. First-class support for relationships

8. Deeper integration with Graphback (but still not dependent on it) thru code generator/client side queries

9. Simplicity to start with datasync use cases using datasync-starter
   https://github.com/aerogear/datasync-starter

10. Ability to work with plain graphql queries

11. Ability to upgrade datastore (impossible with cache - invalidation is the hardest thing on universe)

Notes

This is just created as proposal any edits/suggestions welcomed

[wtrocki]

Since we already have datastore prototype let's discuss those and see if we can build some early set of issues to build this.

[Eunovo]

Ability to see offline changes and being able to differentiate between change that was made offline

@wtrocki from the DataStore perspective, changes that will be considered offline are those that have not been synced with the server. We can have API that tells if a particular change has been synced. Like

const item = (await DataStore.query(Note))[0];
console.log(item.isSynced)

We can implement this by checking if the lastUpdated is before our last sync with the server.
WDYT?

[wtrocki]

@Eunovo Exactly this! There is no way you can do that now in the offix 1.0 as we are dealing with the cache and optimistic response flag is not being returned from client (as everything is the graphql query driven)

[kingsleyzissou]

Would nr 2 get rid off the need for an offline queue, in the sense that we would could have a computed list of changes based on the items that have not yet been synced?

Or would there still be value in keeping an offline queue?

[kingsleyzissou]

What I would like to see is a simple setup with little fuss over how to configure the client and the store and all of that.

It would be nice if we could have a simple and clean way to setup the offix client, that would be amazing.

[wtrocki]

Or would there still be value in keeping an offline queue?

We need offline queue to stage original changes in history as datastore entities are in merged form. Also it is needed for rollback etc.

[wtrocki]

It would be nice if we could have a simple and clean way to setup the offix client, that would be amazing.

Yes. Single js package and flags for feature enablement. Custom storage implementation with default available out of the box