Is GroundDB the best for offline storage?

Is GroundDB the best for offline or is there a newer solution? I want something where my App is still showing cached data even if their mobile connection / wifi is off. Just like how youtube works.

Thanks guys

2 Likes

@captainn is the best one who can advise you on this matter.
In the mean time, check his repositories.

1 Like

Ok roger that, small world I already have seen his repos before! Awesome work

yeah, the meteor community isn’t that big :sweat_smile:

I use ground:db, but I also keep a copy in my local packages folder, just so I can update the dependencies. I once tried to fork it, and get the official package up to date, but I ran our of time, and never finished that effort. It does work out of the box, even in 2021.

3 Likes

Ok thanks man, I’ll give it a try!

Hello @truedon and @captainn! I use grounddb in my cordova app and it always worked perfectly.
I recently upgrade to meteor 2.5 and it stopped working with no errors, it just doesn’t connect with local db anymore. I’d like to know, are you guys using meteor latest versions with grounddb?

Thanks for the heads up, I’m about to start a new project in 2.5 and didn’t try yet. I guess you can try running with debug on and doing some console.log on all objects to see if there is any hints as to what is briked. There is a issue with security certs on older meteor packages but I don’t know if that’s relevant here at all just throwing it out there to consider. I’m about to fork a @captainn starter and try updating so will report back if I get any news

Thanks! I’m still working on it. What I’ve found so far is that GroundDB works the first time I write/read some data, but after making some changes to the code that updates the app, it no longer connects to offline collections, although they still appear in the LocalStorage. By the way, I’m using this settlin:ground-db fork because of problems I had with EventEmiter in one of the original package’s dependencies. Any news I’ll post here.

2 Likes

Have you tried adding debugging to the connection and see whats up?

Yes, I think… it’s only client code with offline collections. Here’s some steps to reproduce the problem:

meteor create test-app --blaze
meteor add settlin:ground-db (or some fork that works)
meteor add-platform ios
meteor run ios-device

An example app:

<head>
  <title>test-app</title>
</head>

<body>
  <h1>Welcome to Meteor!</h1>

  {{> hello}}
</body>

<template name="hello">
  <button>Click Me</button>
  <p>    
    {{#each list}}
    {{this._id}}
    {{/each}}
  </p>
</template>
import { Template } from 'meteor/templating';

import './main.html';

export const testCollection = new Ground.Collection('test_collection', { connection: null });

Template.hello.helpers({
  list() {
    return testCollection.find({});
  }
});

Template.hello.events({
  // Insert some persistent data
  'click button'(event, instance) {
    testCollection.insert({ 
      _id: new Date().getTime() + ""
    });
  },
});

After adding some data to the collection, if you close the app in the simulator (or refresh via web inspector), the collection is no longer listed. But if you look at the storage tab, under indexed databases, the data is there. The data is persisting correctly, but the app connection of this data is not.

Is this because it’s the simulator or you can replicate on the real device also?

I can replicate on real device too.

I wonder if it’s something caused by an update to prevent tracking or something that’s all that comes to mind

I’ll discover later in which specific version of meteor this problem starts… I’m keeping my mobile app working with meteor 1.11.1

1 Like

I found that the internal API in LocalCollection that ground:db uses switched from an object to a Map sometime around Meteor 2.4. I didn’t think to look at any of the forks. Rather, I did a from-the-ground-up (pun unintended) rewrite, which I’m calling GroundedCollection. I switched to Typescript, added the ability to specify compression/decompression functions for writes/reads to IndexedDB, and switched from localforage to Dexie, but otherwise tried to keep the API similar.

As a bonus, Dexie allowed me to use bulk reads/writes, which decreased load times by an enormous amount – I can’t remember the multiplier but it was in the tens if not hundreds of times.

It’s not packaged or anything, but it’s been running in production for a couple months now with no issues, so I will share it here in case anyone would like to use it:

11 Likes

Neat! I had been thinking of trying a ground up rewrite myself - glad someone beat me to it!

Awesome stuff man thanks for sharing!!

The problem of persistency I mentioned earlier starts in Meteor 2.3

This is awesome! Thank you very much for sharing this! :raised_hands: