My Meteor app magically has offline capabilities

[chriskgregory]

I have been working with Meteor for awhile now, but I just finished my first app where I fully utilize stubs. I am actually perplexed in a good way. Hopefully somebody can explain the functionality I’m seeing so I can better understand it and maybe even benefit from it more than I already am.

I have user profile settings that change based on input changes. These are methods. I accidentally found that if I have my app completely disconnected from the internet, and make these changes, then later reconnect to the internet, it will update the collections with the proper changes. How does it do this sorcery?!!?

I was just at the point where I was about to learn how to use Ground:DB, but now I’m wondering why I would even need it? What is are the limitations of this functionality and how can I harness it?

[waldgeist]

This is called “optimistic UI”. Meteor simulates, on client side, the effects of any updates to the server and syncs with it as soon as the connection is established again. This even works for methods, if you let them run on both client and server. So effectively, a method will be run twice: on the client for simulating the changes, and then also on the server to perform the actual changes. If there are any conflicts, Meteor will drop the client-side changes.

[robfallows]

You may find this useful, which discusses simulations, connection failures, subsequent actions and collection mutators.

[alawi]

The goal behind Optimistic UI seems to fake quick responses to the user by simulating server responses at the client for usability purposes. But I think chriskgregory is also interested in knowing how this technology can be leveraged to handle full offline experiences. Are there any limitations in harnessing this technology for offline support that you guys ran into? did you guys try to push these techniques to have reasonable support for offline experiences?

[robfallows]

It’s not a particularly robust way of dealing with going offline - it’s more for minor connection outages than planned/long term local running. Local data exists in memory only, so closing the browser, for example, loses it. That’s when GroundDB is more useful.

[alawi]

Always insightful answers from @robfallows, I’ve learned a lot reading your comments, thanks!

[chriskgregory]

Thank you so much @robfallows. I have read MANY of your posts/replies over the years!

[chriskgregory]

I’ve been running tests on simulations all night, and found that when they complete, they do not return a result. Therefore I was able to place Meteor.status() checks to allow for an alternate code block if a method wouldn’t return a result from a method call (offline). This allows full offline functionality as long as you do not close the app. Pretty nifty - although I will state that AutoForm and SimpleSchema can cause issues, particularly in the if (this.isInsert) for SimpleSchema, where it will override the value of the simulation insert once connectivity is restored and method is rerun.

Fascinating stuff nonetheless!

[waldgeist]

For true offline experiences, you would need true offline storage as well. In principle, this is possible, but quite tricky since there is no “best-practice” to achieve that and you have to try out several options supported (or not supported) by the respective devices.

I started a discussion on that issue in February, for your reference:

Cordova: Best way to store persistent data on client-side?

I want to add a teaser slider to the start page of my mobile app. This slider should show up only once per device, so I want to store that the user has seen it locally. What’s the best-practice approach for storing persistent data on mobile devices? Would it be HTML5 local storage, or are there other options? Maybe even packages? EDIT: Ideally, the solution should also survive any app updates from the app-store.

The thread also includes a response from Martijn, who is the owner of Meteor’s Cordova integration part.

[chriskgregory]

Thank you @waldgeist for that great read. I’ll be doing a lot of studying up on localstorage and groundDB. I did a lot of work today and actually found that SubsManager helps a lot with simulation usage due to the caching. I would need a lot of necessity to implement something more than simulation can already offer. What a fantastic platform Meteor is…

[nosizejosh]

@robfallows thank you so much for all your help. I have an app that must be offline first. with my current implementation, I realise method will retry when connection is gained and sometimes produces multiple results of the method call, and this is because;

1. the method are not available on the client when action is called at offline status.
2. there’s no feedback to user that the method failed.

I have looked at grounddb, but I believe it doesn’t solve my methods problem or maybe I still dont understand how to use it.

how do I setup my app so that some methods at least, so that when the app is offline, some functionality is still available?

[robfallows]

I don’t know what client technology you’re using, but here’s an excellent guide to offline first by @spencercarli with React Native and Meteor. Perhaps it will spark some ideas if nothing else

[nosizejosh]

@robfallows thank you, will check out the link now. I am using blaze. Does that affect how i structure my methods to be available offline?

Thanks again. You have been a great help on my meteor journey.

[nosizejosh]

@robfallows, I have read through this before while researching the issue. I could wrap my head around it much, maybe also because it was react and redux stuff. I will look at it again. But my question is around methods, how can you make some methods available even when offline.
Eaxample,

Meteor.call('links.insert', title.value, url.value, (error,result) => {
      console.log(error,result);
      if (error) {
        alert(error.error);
      } else {
        title.value = '';
        url.value = '';
      }
    });

This method will keep retrying until connection is restored and execute, from what I understand. What if there is a way to run another method instead when offline? Is my thinking wrong? what i’m I missing?

[robfallows]

Methods can co-exist on the client and the server. Methods on the client are often referred to as simulations - they don’t have access to server resources, so they simulate the actions to be done. When the method completes on the server, the results are used to update the simulation to match what actually happened on the server.

I highly recommend reading the Meteor Guide on Methods, particularly the Method call lifecycle. A good understanding of that is key to developing good offline behaviour.