Setup meteor app to be offline first

I have an app that must be offline first.
I have researched this and implemented as much as I can. with my current implementation, I realise method will retry when connection is gained and sometimes produces multiple results of the method call, and thia 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 are available on the client, so that when the app is offline, some functionality is still available?

This is one of the special features of Meteor actually :slight_smile:

@herteby thanks for replying,

my challenge is aorund how can you make some methods available even when offline.
Example,

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? how does meteor help with this?

Just detect if offline and call another function?

You can use Meteor optimistic UI to simulate running the method on the client, but it’s designed more for optimistic UI then full offline experience. You need to define your overall offline first strategy and technology, as far I know Meteor doesn’t really provide offline first mobile experience out of the box.

1 Like

Try https://pouchdb.com/ with Apollo.

You will have to devise creative solutions to your problem. I don’t think there are many solutions out there in the public space at this moment.

My plan;
if I can call a “client only” method, i will be able to then affect the client only mongo or the groundb database and then sync the difference in db when back online.

  1. Is my plan a way to go?
  2. how do I get a client only method?

Thank you.

A client-only method is really just a function - it doesn’t need to be any more complicated than that.

@robfallows but from all i have read, some from you, methods on the client are dangerous and pose a security risk. so how do i do this securely? I have been reading on the methods as u suggested since morning but still cant get to how i can implement what i want.

I don’t think I’ve ever said that. On the other hand, you definitely don’t want to trust the client blindly.

What you could do is have a local FIFO of mutations (redux may be a good way to do this, but you could do it with minimongo). As the client does things it basically writes a replay log locally and makes assumptions about the results (optimistic UI - in a do-it-yourself way). When a connection is made to the server the replay log is played back as method calls to the server and actual results are used to update future replay log actions. As far as the server is concerned, it knows the id of the user at that point and can perform business logic securely - or reject the request.

It really depends just what your app needs to do locally as to how feasible/complex this turn out to be.

I understand pouchDB, but how does Apollo add additional value over Meteor methods for offline mode?

I think robfallows is stating that it’s just a client side JS function that will get called.

Correct me if I’m wrong but I’m assuming you’re new to this, if I may suggest you start basic with online first (since the framework gives you that out of the box) and then once you get a better grip of the technology then you can tackle the more complex task of offline first.

If all you want is offline mobile app, then you might want to consider something like react native.

1 Like

@alawi I’m not new to meteor :slight_smile: but rather to this particular project and requirement is. @robfallows sent a link to an implemntation with react native and it looks like i have to go with that. I have been fighting off having to learn react. Blaze has been ok for me :frowning:

2 Likes

Thank you. I am breaking down your ideas now.

on the security issue, this is what I was referring to. Maybe I dint understand what you meant.

Thanks again for the ideas.

1 Like

All that means is make sure that any sensitive code only gets put on the server. If you want optimistic UI, then you’ll need to have a client version of the method which provides some dummy action using non-sensitive code.

1 Like

OK got it,
Thank you

1 Like

Got it, well again, if you want full-fledged ‘offline first’ mobile experience then I don’t think Blaze and Meteor methods are designed to solve for this out of the box. You’ll definitely need to add more tools to your skillset and to the stack.

Generally speaking if you want “offline first” you need a solution that caches the data on the client and sync back to the server when the connection comes back on. Take a look at this article to see what that might involve with react native and Meteor, it’s by no means trivial.

1 Like

@alawi same link @robfallows sent. you guys thinking are in sync and offline capable! :smile:

1 Like

haha! I was in offline mode when he posted that it seems :wink:

1 Like
Sorry to revive an old thread,

but this is one of the top search results on Google for Meteor.js offline support, so I think it it relevant to post here.

It seems Meteor has everything we need except for minimongo being cleared on refresh.

Maybe the only thing we need is a simple boolean option for minimongo to persist locally (with a way to clear cache for certain collections, or maybe persist only for certain collections, etc).

Other than that, Meteor.methods need to be loaded on both server and client for the “optimistic UI” (which means the client can change the data locally before syncing to the server, but that also implies that if we are offline, the local data will be updated and the UI will update, and the server will sync later once online).

At the very least the methods that have the logic to update collections for the UI should be imported on both sides for this to work smoothly with default Meteor features. Methods for online-only can have placeholder methods on client.

If your server methods are visible in public, you’ll probably end up with the best security (if not careful, someone will first exploit you). Just be careful. Nothing wrong with showing code publicly if it is actually secure.

So the real question this boils down to is: how do we persist minimongo over refreshes?

Some options:

I think it would be great for Meteor to make persistence an built-in option for it’s collections, but even so it isn’t difficult to implement the persistence part (just look at the size of those packages) or to just use a package. Means it is also easy to add this to Meteor core.

1 Like