Caching minimongo data in the browser for faster startup

performance
1

Users often want to open multiple instances of my app. This requires that the whole Meteor app loads again from the server into a new browser window. I’ve sped this up as much as I can with appcache and AWS CloudFront. The biggest bottleneck now is setting up the DDP connection and downloading the data.

Is there a way to cache the minimongo data in the browser?

Any other ideas would be appreciated too. Perhaps if I was to wrap the app in Electron I could somehow share a DDP connection? Can multiple browser windows share a DDP connection?

2

How much data is required at startup? In the apps I’ve worked on the load time is entirely the server bundle, but even that is almost always < 1 second because the browser caches the js and CSS. So im surprised to hear this is a problem, are you running any subscriptions that return more data than required?

3

maybe you can try https://github.com/GroundMeteor/db

4

I did some investigation and it’s because the DDP server is so far away. I’m in South Africa and the DDP server is in California. It takes about 5-6s for the app the load from here, but when I try with a cloud browser in Virginia, the whole thing loads in <1s.

5

That project looks very interesting, possibly just what I need.

I’m a bit nervous because I see the last commit is Nov 26, 2017. Are you aware of anything similar that is more current?

I can think of a few ways to use it:

  1. Use Ground DB cursor until the ordinary subscriptions are ready, then swap. Hopefully this doesn’t cause the UI to flicker. I’d have to block updates until the ordinary subscriptions are ready

  2. Use the Ground DB as a syncing proxy for the ordinary subscriptions. It’s not clear from the docs how well this works, server to client sync seems to work easily with “observeSource”, I’d have to fiddle to see if the reverse works

  3. Fill the local collection with the stuff from the Ground DB at startup. The client will then try to insert these on the server when the subscription is ready though. Maybe I can block that somehow…

Any suggestions would be appreciated.

6

We use grounddb to enable offline support - our users select what data they want to take offline, and we stick it in grounddb. We wrap a collections CRUD methods to detect if there is no connection, and use groundDB in that case.

If your data is read only you don’t need to worry to much, and observeSource will work nicely. You change all your reads to be from the grounddb collection. You might need custom logic to ensure that when the site loads and there is no data available from the observed source, that ground DB doesn’t remove data. For example, manually watching methods for the “removed” messages.