We’re seeing more and more solutions integrating offline synchronisation, especially for mobile apps.
Will it be the case with the new Data Layer with GraphQL ?
EDIT: Here are some examples:
http://www.couchbase.com/nosql-databases/couchbase-mobile
http://kinto.readthedocs.org/en/latest/
https://strongloop.com/strongblog/node-js-replication-mobile-offline-sync-loopback/
IMO moving and synchronizing data between client and server is the “it” feature of Meteor. I can’t imagine they would drop it if/when they move to GraphQL.
I’m talking about offline synchronisation with conflicts resolution mechanism.
For example, if I don’t have my internet connection anymore, change some data that are localy stored then get back the connection but the data I changed also changed on the server, so there’s a conflict and it needs to be solved.
This is a very different topic and that can be quite complex.
Actually the old Minimongo system was not so good for offline data, since when you reconnected, you would have to reload all of the data from scratch if you were disconnected for long enough.
The new system should be able to load only the changed data when it reconnects, making it much better for offline-first reactive apps. You might still need to do some conflict resolution but I think it will be a big improvement. It will also be easier to integrate with native apps since all you need is a GraphQL client, or, in the basic case, just an HTTP client that can make POST requests.
@sashko Thanks for the reply 
At least it will reload only the changed data, which is already very good.
If you plan to include conflict resolution, you can take a look at how LoopBack does it, they explain all the mechanism here: https://docs.strongloop.com/display/public/LB/Synchronization
It’s also open source and written in Node, so maybe you can take some code from their mechanism.
(From a Matt presentation at Stanford) I thought Meteor left conflict resolution to the database. So in the case of Mongo it’s last write wins, regardless of the time spent disconnected.
Yes but that is talking about writes, with offline support you also have to worry about reads.
Registering my interest on this one too - disconnected clients will be an important part of our product going forward so not having to code all of this in a separate app would be a big plus for us.
Conflict resolution seems to always end up needing some level of custom business logic, so as long as there are clear hooks to adding that in it seems sensible to leave it to the implementing code to me.
@sashko do you have any sort of rough target time-scale on when there might be something available for testing (are we talking months or over a year say)?
It’s hard to predict since we have only done some prototyping, designs, and experiments and haven’t really started building anything real yet, but hopefully we will have something useful on the order of a few months. We want to start from the base components and build upwards, so hopefully we will have something working soon, even though the developer experience might be worse, and then we can build nice layers on top of it.
That’s awesome, thank you. Completely understand that it’s very early days at present. If you want testers for the disconnected stuff just let us know.
What would be the differences between the actual GroundDB package and the futur data layer? cc @raix @sashko
I’m very interested in this offline stuff improvements too!
I’m not really fit to answer - I haven’t been involved in the new data layer. (I’ve looked at the apollostack org repo’s but seems much like wip)
Not sure if mdg is adding real offline support, for offline first applications - might just be caching of data. (probably already exists in relay?)
Kind regards Morten