jam:offline is an easy way to give your Meteor app offline capabilities and make it feel instant. Its key features are:
Offline access – Saves Minimongo data in IndexedDB for offline access and instant reloading when reconnected.
Automatic syncing – Syncs offline actions automatically once reconnected.
Cross-Tab syncing – Keeps changes in sync across multiple tabs while offline.
Seamless reconciliation – Reconciles data with the server when reconnected.
It’s customizable so you can configure to your liking.
There’s been a lot of previous discussion about ways to build offline-first or local-first apps with Meteor. jam:offline is designed to make this easy.
The Readme also includes instructions on how to add a service worker to cache your app’s static assets and take the next step by converting your app into a PWA.
If you end up giving it a go or have ideas on how to make it better, let me know!
Your packages are a breath of fresh air in the Meteor ecosystem.
I like your automatic approach to offline persistence per collection configuration and with filters! This package could quickly become essential for many Meteor apps. Congrats!
Minimongo data is persisted to IndexedDB which means it will work for any app that can use IndexedDB.
For mobile, this means if you’re using Cordova (which uses a web view) or it’s a PWA, it will persist the data as expected when the user closes the app. When they come back, it will first load the persisted data and then perform the server sync if needed.
For those interested in creating PWAs with Meteor, I published a starter kit here:
@jam does this package also support offline login (or more specifically app restarts, without logging out), or do you have any hints on how to implement this?
Thanks for the starter kit. I see you’re handling push events in there too. Given the main client app is sleeping - what service do you use to send those ? I’ve seen firebase mentioned plenty but wondering if there’s something else. I checked progressier out once but never got round to implementing anything.
@koenlav if the user is logged-in, goes offline, and refreshes the app, they can continue using the app. This package persists their user data in IndexedDB so they won’t be logged out automatically. This assumes that you’re also caching your app’s static assets with a service worker – you can take a look at the pwa-kit link above if you don’t already have one set up. Is that what you had in mind?
For native mobile push notifications, in the past I’ve used firebase and Apple’s APN, which was a pain . Maybe others here have some good recommendations for alternatives. I looked at OneSignal too in the past but didn’t like their data privacy policy.
I think with a pure PWA you could probably just use web-push for all platforms (now that Apple in theory supports it). Though if you’re sending a lot of notifications, I’d imagine you’d want this running separately from your main app.
Thanks. I’ll have a look. So when people setup this kind of thing, do people typically stop sending notifications on the client side altogether (we subscribe to a notification pub at the moment and use a simple push library there) or you handover when you notice the client goes offline ?
This seems to be a great package to give it a try, thank you for this.
I have one question about the queueMethod.
I’m trying this package for my mobile app (Meteor/Cordova based) which is connected through DDP to another MeteorJS app’s server and all the data, subscriptions and methods called belong to that specific app.
Can the package handle method calls through DDP? Can queueMethod handle where to call these methods? Can we handle replays on a different Meteor server?
e.g. This is how method calls are made in my mobile app:
Thanks! Currently, the package uses Meteor.applyAsync when replaying so I don’t think that will work out of the box for your scenario.
I haven’t looked into it this too deeply but I assume it could be supported in a future version. Is there a programmatic way to get access to the DDP url? If so, one idea would be to check its existence and use it to invoke the methods instead of Meteor.applyAsync. Otherwise it could be specified via a config. Let me know if you have ideas here.
I don’t think there’s a general programmatic way to check if the app is connected through DDP with another and get access to the DDP url.
For my scenario, the DDP url of the DesktopApp is specified in Meteor.settings of the mobile app and accessed from there in the app.
I assume providing the DDP url as a config somewhere would be the best approach.
More like Meteor.settings.sofisai.ddpUrl is the path to the DDP url, where sofisai is the name of the DesktopApp.
A bit of context: The mobile app is connected to various systems/Meteorjs apps through DDP URLs, but it’s the sofisai module within the app that I’m trying to make offline-mode capable.
I’m keeping an eye on updates for this matter with methods replay over DDP. If I can give you some insights or code snippet on how I’ve established the connections to call another Meteor server for the Mobile App (to make your development easier, if you think it helps), I’m glad to help.
Otherwise, I’m really invested to continue the development of the offline-mode using this package and a support on this matter is highly appreciated.
. Maybe others here have some good recommendations for alternatives. I looked at OneSignal too in the past but didn’t like their data privacy policy.
