One of the most common questions I’ve been asked about using React Native and Meteor together is how to make it work offline. I spent some time thinking about that and formulating a potential solution. Would love some feedback on it!
Happy to answer any React Native + Meteor questions you may have
4 Likes
Have you thought about using Realm here? I’ve not done any benchmarking personally but I’d wager it will laugh in the face of asyncStorage.
Also their new platform is an interesting solution to the offline problem (if you can afford it).
In general, my experience of trying to make offline work using DDP was frustrating. A lot of the magic that makes life so easy can also work against you when connection quality is poor.
Some things that I learnt:
-
You can’t timeout a method call. It just sits there waiting to reconnect. This is great in principle but sometimes you want to have more control.
-
Meteor.status()
uses exponential backoff which is nice but sometimes you want to sync now dammit so you need to use Meteor.reconnect()
-
You may already handle this but we found pub/sub less than ideal because of the way you could lose data on app restarts. We wanted true persistence through restarts and HCPs.
-
Scale and Performance. You have to handle when a app has been offline for a long period and there is a flood of updates. We ended up using batching for our offline sync routine. And data has a habit of growing so you need a store than can handle larger volumes.
-
Errors. Network transmission failure happens fairly often (it turns out) and you need to handle retries gracefully.
-
User feedback. Providing status in the form of some form of pending count shown to the user prevents confusion.
-
conflicts…
After trying various approaches to solve these problems my next iteration will likely use Realm and pure HTTP calls. That said, I never really played much with observers and it would be nice if it could be made to handle the stuff above.
1 Like
I haven’t tried it but I do agree that performance would be much better. The issue arises with the necessity to define a schema with Realm which makes it hard/impossible to write a simple API that hooks into DDP and “just works”.
Interesting insights from your experiences - I appreciate you sharing them!
You may already handle this but we found pub/sub less than ideal because of the way you could lose data on app restarts. We wanted true persistence through restarts and HCPs.
That’s the primary goal of this code - it’s certainly a pain otherwise.
Scale and Performance. You have to handle when a app has been offline for a long period and there is a flood of updates. We ended up using batching for our offline sync routine. And data has a habit of growing so you need a store than can handle larger volumes.
The “debounce” in the code should help with this issue so that it can wait until the bulk of writes stops/slows and then make a single expensive write to disk.
Really cool. Thanks for sharing.