Great!<p>I'm really no expert, but I think that language-specific persistent in-memory databases are the way to go.<p>Deep inside, what I really want on my backends is just a data structure. A single big tree (or graph) of objects. Some primitives to make it thread-safe somehow (immutable collections, or mutexes, or just old-fashioned single-threadedness like Node - whatever), and that's it. Requests from the client query and mutate that data. In <i>very many</i> situations, I wouldn't need anything special to make this work fine with an application up to a pretty large number of users. Not all apps do big data analyses. RAMs are gigantic these days, bigger than the SQL datafiles of swathes of webapps.<p>However, there's that pesky problem of code upgrades and crashing servers. If my server would never crash and I could hot-swap the code, I wouldn't need persistence at all. But I do, so I don't just want an in-memory datastructure, but a <i>persistent</i> in-memory data structure. I want to use this datastructure as easily as the programming language could possibly make it be for me while still guaranteeing some sane level of persistence and fault tolerance.<p>Redis is a nice idea, but the fact that it's a separate server, with a client and a protocol and data structures that <i>just not precisely</i> map to my programming language's data structures force me to write a whole bunch of boilerplate anyway. Even more so with other databases like Mongo or Postgres.<p>If I understand it well, Loki doesn't entirely do what I'd want: it does not save the data to disk on every change, but less often, if I get it right. That might be good enough if my problem allows for many little independent Loki databases, but if the dataset is a gigabyte and persistence means flushing that whole gigabyte to disk after every data change, it probably won't work very well.<p>I'm really curious if other people here have similar ideas, maybe implementations, of these concepts. Maybe Loki could be extended with a snapshot+operation_log type of data storage like Redis has and then it'd be pretty close.
Related: SQL.js, which is sqlite compiled with emscripten<p><a href="https://github.com/kripken/sql.js" rel="nofollow">https://github.com/kripken/sql.js</a>
From skimming the presentation it looks like a project similar to Meteor's Minimongo and Miniredis (<a href="https://www.meteor.com/mini-databases" rel="nofollow">https://www.meteor.com/mini-databases</a>) used for browser caches. Minimongo, for example, implements a great majority of Mongo selectors (there are no secondary indexes, though).<p>(I contributed to both Minimongo and Miniredis)
How does this compare to DataCollection.js?<p><a href="https://www.npmjs.org/package/data-collection" rel="nofollow">https://www.npmjs.org/package/data-collection</a>
<a href="http://thestorefront.github.io/DataCollection.js/" rel="nofollow">http://thestorefront.github.io/DataCollection.js/</a><p>They look fairly similar. What's the test coverage and do you have performance benchmarks?
Excellent project, there needs to be more focus in this space. I've been feeling a general trend of developers going back to basic embedded databases.<p>I'm working on a similar project, that is focused on ease of use combined with distributed/decentralized (concurrency safe) behavior. Http://github.com/amark/gun
Has anyone used this is lieu of or in comparison to Redis? Am I correct in assuming that with LokiJS, one could move in-memory data storage from the server (with Redis) to the browser (with LokiJS)?<p>This project looks quite interesting. Thanks for sharing. Could be a great solution for single-page web apps (and mobile, Cordova, etc.).
This looks interesting. Coincidentally I was just searching around for something like this to run in the browser.<p>I'll play around with it myself, but is there anyone who has used this that knows how well it does with memory usage?