Let’s say Meteor converted livequery to sit on top of IndexedDb in the browser, enabling live data queries. How would that work?
Context:
1 Like
I think this is a great idea regardless of the API, but I would consider two things:
- Is browser support good enough for people to use this in real life? (possible solutions: have this be a meta-API across several types of storage, where there are fallbacks when indexedDB doesn’t work)
- What are the possible use cases? Is this going to be used to cache data from server-side collections, or is it for general application state? The answer to this might affect some design decisions.
Excited to see more stuff like this! Even if (1) or (2) aren’t answered, this library would be great to build on top of for package authors.
For support: http://caniuse.com/#feat=indexeddb it’s meh-ish - 79%, not sure if there are widely accepted polyfills out there, but I’m sure there is one out there somewhere.
Yeah, it would be great to have some sort of fallback, whether it’s localstorage or something else.
I think this would be a case where Meteor has been a first mover on figuring out the solution to a common problem (client side DB APIs with reactive UI layers), and we should offer our solution to the wider web community by way of connecting to a standardised database. I don’t think it necessarily needs to be part of the Meteor API itself.
I’m very excited for a good alternative to localstorage with a nicer API, since there are a lot of situations where you want to store some data on the client.
This is scary:
Is this a suggestion as a common back-end for the mini-* (mongo, sql, etc.) client datastores or a way to have offline data?
It would work for offline data, but the real motivation for me posting this is that I think Meteor is onto something with minimongo and I’m interested in bringing it to more people (even if they don’t use Meteor).