meteor / meteor-feature-requests

A tracker for Meteor issues that are requests for new functionality, not bugs.
Other
89 stars 3 forks source link

Use IndexedDB as alternative storage for minimongo #407

Open SimonSimCity opened 3 years ago

SimonSimCity commented 3 years ago

Using IndexedDB as a data-storage for minimongo would give us several advantages, I think, e.g. of automatically having indexes built in (#66). In addition it might clean up the code-base we're using and have even more critical parts of the codebase working on standardised solutions.

One major downside I see so far is that many of the calls are asynchronous (based on callbacks) and could therefore only be introduced on the client if we would switch to a promise-based interface for database-calls.

This idea arose after having had a look on this repo: https://github.com/mWater/minimongo

Torgen commented 3 years ago

One issue with IndexedDB is that data has a same origin policy, so if you have multiple tabs open all tabs can see data from all other tabs. This means you have to query Minimongo for exactly what you want instead of just assuming that what's there is only what you're subscribed to. (This is already good practice.) Also, when you close a tab, does Meteor get enough time to clean up the data from the disappearing subscriptions?

mitar commented 3 years ago

Yes, Meteor should have also version information for every change. Then this would work for our advantage, syncing only newer changes from the server.