Conversation
It would be great to have some official guidelines on how to make Meteor apps to work offline and synchronize back with main database after the Internet connection is established. It's an important use case especially for apps frequently used in phones.
@brajt: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/ |
This is actually a bit of a pain point with Meteor right now - it's not quite designed to work seamlessly across long reconnects. A fair number of people have been asking for better answers about this topic though in my memory. I imagine the closest solution right now would be something like GroundDB? https://atmospherejs.com/ground/db Maybe we can get the authors on here to see what they think - @raix @urossmolnik, do you think GroundDB meets this requirement well? Is it something we should include in the guide? Are you guys using it in production? |
In my case it's rather "I plan to" than "I do". It's a crucial functionality for the app I'm writing, but development of it is not at the stage when I'd worry about this matter yet. I was just inspired by the recent discussion on forums and thought it would be great to have this topic touched by the Meteor Guide. However, if you decide it's not important enough, it's fine for me. |
Can you elaborate more on what functionality you want in your app exactly? The best thing we can do to get some information in the guide is to get a lot of really specific data so that we aren't writing about something people don't actually need. |
I suspect the answer is rather than "we don't think it's important", rather "we don't have anything definitive to say". I'm not sure we want guides that are less than definitive on a topic @stubailo? |
I feel like if there is a very important topic where we don't have anything to say, we should figure out what to say, no? Or do you mean that there won't be a one-size-fits-all solution for offline data? |
What I mean is that a 'guide' that's just a collection of ideas and "try this package, it does some of what you need" isn't that helpful. I think that kind of experimentation is best left to community efforts like the Meteorpedia. Not to say we shouldn't have a open PR/issue/md file that's like "we need a better story for offline mode, we need to fill in these blanks somehow, hint hint community" -- I just don't think we'd publish it yet. |
I think you're right. Let's keep this open a while and see if anything comes out of it. |
In my case it's a simple "be able to read and edit text documents (creative writing) in offline mode without the need to export them outside of the application". So as it's not a complicated case, I'm pretty sure one of already existing solutions like GroundDB will do a good job here. I agree that if there's no official thought on the topic yet, there's no point to write about it in the guide. Then, just +1 from me for a better story in Meteor for offline mode. :) |
I'm rewriting Ground:db at the moment, we are using it in prod. Its not just about offline support, its also a way to scale. Eg. Resuming a session instead of sending all the data to each time - something to come. |
OK let me know when there are developments! |
I saw some demos sampling offline implementation. While i haven't seen really good production cases/material about the subject, maybe a basic guidance can be done with the resources today available. A warning that a more advanced usage like 'sync conflict resolution' is yet maturing in the community should be explicit too. Good news @raix sounds relieving you are looking at this feature improvement. |
@fabiodr yeah, I'm planning some time for it in december if time and @jperl allows it |
I think we might not include this in the initial version of the guide. Meteor is currently really not designed for this use case - "some demos" is not really a good base to make a recommendation from. Is there evidence of someone using this stuff in production successfully? |
I've collected some resources about it. Maybe helps here. There are published samples of the repos too.
|
https://github.com/subvisual/tripl.it Hey, just realized this one is a production mobile app published in Google and Apple Store :) They even stated in the repo description that choose Meteor because it has easy offline implementation (using groud:db), if i got it right.
|
I'm fine with this topic not being included in the initial version of the Guide, but hope it will hit it later. :) |
What is the progress on this? It seems the pull request got stalled? |
Filed an issue: #233 |
It would be great to have some official guidelines on how to prepare Meteor apps to work with data in offline mode and push the changes to main database after the Internet connection is established. It's an important use case especially for apps frequently used in phones.
I imagine the closest solution right now would be something like GroundDB? https://atmospherejs.com/ground/db
Maybe we can get the authors on here to see what they think - @raix @urossmolnik, do you think GroundDB meets this requirement well? Is it something we should include in the guide? Are you guys using it in production?
Not to say we shouldn't have a open PR/issue/md file that's like "we need a better story for offline mode, we need to fill in these blanks somehow, hint hint community" -- I just don't think we'd publish it yet.
I agree that if there's no official thought on the topic yet, there's no point to write about it in the guide. Then, just +1 from me for a better story in Meteor for offline mode. :)
While i haven't seen really good production cases/material about the subject, maybe a basic guidance can be done with the resources today available.
A warning that a more advanced usage like 'sync conflict resolution' is yet maturing in the community should be explicit too.
Good news @raix sounds relieving you are looking at this feature improvement.
@stubailo can we sync up some time and talk about "resumable" subscriptions sometime? - I know the code was semi in there but was removed by @glasser in a cleanup - It would be valuable to have a way of resuming subscriptions and only sending the actual updates, but kinda hard to do atm without rewriting / hacking core.
Is there evidence of someone using this stuff in production successfully?
http://triplit.groupbuddies.com/
Hey, just realized this one is a production mobile app published in Google and Apple Store :)
They even stated in the repo description that choose Meteor because it has easy offline implementation (using groud:db), if i got it right.
"This version of tripl.it uses meteor. The reason for that is the out of the box offline database, synchronization and conflict resolution."