Updated April 6, 2016
Pub/Sub versus Methods in React Native Meteor
Originally publish on medium.com.
This week’s post is a short one and more of a thought exercise rather than a tutorial. It stems from a comment made by Abhi Aiyer on a recent edition of the Crater podcast. He made a great point about using Meteor methods rather than Meteor’s pub/sub system for mobile applications.
Why?
If you’ve developed for a mobile platform you know that internet connections can be spotty, slow, and drop randomly. This isn’t a great situation when you’re building an app that depends on a constant connection to create your real time app. How does your app respond when the connection is reestablished? What happens if your user makes a new subscription when they’re not connected to the internet? How does your UI manage a drop in connection?
There are quite a few cases… so why try and handle all of those if you don’t have to?
But what about reactivity?
One of the most appealing things about Meteor is the out-of-the-box reactivity — it’s awesome! I won’t deny that. This is simply an exercise to think about what needs to be reactive versus what doesn’t.
For example let’s look at an app like Instagram. You probably don’t want the feed to be reactive, what happens to your scroll position if a new photo is posted when I’m 30 pictures down? What if I’m reading the most recent comment and then someone else comments? Where’d the comment I was just reading go!
On the other hand the dedicated commenting view could be a good example of a reactive screen. You may want to see new comments coming in as they’re posted — like a real time chat.
These are a few instances of when a method may the right solution and when a pub/sub setup may be right. Consider your use case and remember that you can use a method similar to a REST endpoint :).
I hope you found this thought exercise beneficial and applicable (even if you’re not using React Native). Thanks to Abhi for bring this up!
