3 ms·

The way I understand it, a replacement for Minimongo just for reading data needs two things: 1. A simple filtering/querying API (doesn't need to be as fancy

The way I understand it, a replacement for Minimongo just for reading data needs two things: 1. A simple filtering/querying API (doesn't need to be as fancy as Mongo) 2. Change events on filtered views of data so that you can update the view when new data comes from a subscription If you also want Meteor Method-style optimistic UI, then you need: 1. Tracking of temporary changes from a specific method 2. Ability to roll back those changes when DDP tells you it's done Having a mongo-specific syntax isn't crucial, I think.

marco1 11y ago
Sounds good, thanks! Such an in-memory database seems quite important for productivity, so I will definitely consider this. Read access could be implemented in a first step, while the semantics would still have to be discussed. I think write access would actually be quite important as well so that you can completely abstract away the sending, receiving and processing of events. Latency compensation or optimistic UI would be nice to have (for making applications more snappy), but I think this is only the third most important piece. Maybe one can use "SQLiteOpenHelper" with "name" set to "null" for in-memory storage. Or perhaps some things can be adopted from or based on Minimongo, Realm or MapDB: http://www.quora.com/How-is-Meteors-client-side-database-implemented http://www.quora.com/How-is-Meteors-client-side-database-imp... https://realm.io/ https://realm.io/ https://github.com/jankotek/mapdb https://github.com/jankotek/mapdb