Share Your Use Case for ForerunnerDB about forerunnerdb HOT 4 CLOSED

Hello Irreloon!
I have not used ForerunnerDB yet. Please do feel free to remove this comment if you judge it's out of place.
I just came across ForerunnerDB and it does sound interesting. I looked previously into loki.js and NeDB that are kind of similar to ForerunnerDB but the database is transfered into memory at load time and saved back onbeforeunload (or directly calling commit() .. i guess).
I rulled out both loki and NeDB because of that (in memory: means they are mutable stores) and also because of the fact that data is not automatically persisted (Just loading at startup and saving on leave). This is less than ideal if we imagine that a user encounters some fatal error while using the in-memory database (for instance, if localStorage or indexedDB cannot handle the final size of the data). That would cause all the user's work to be effectively lost.
I'd be using ForerunnerDB as an immutable data store. It'd also be neat if one can chose different storage facilities for different data entities. For instance, some sensitive data must be stored in sessionStorage which means it's erased when the logged in user closes the session. Putting such sensitive data in indexeddb leaves it accessible to other users on the same machine.

from forerunnerdb.

Hey @mehdi-cit your question is not out of place :)

I rulled out both loki and NeDB because of that (in memory: means they are mutable stores) and also because of the fact that data is not automatically persisted (Just loading at startup and saving on leave). This is less than ideal if we imagine that a user encounters some fatal error while using the in-memory database (for instance, if localStorage or indexedDB cannot handle the final size of the data). That would cause all the user's work to be effectively lost.

ForerunnerDB is also an in-memory store but you choose how often (if at all) data is loaded and saved with underlying storage engines.

I'd be using ForerunnerDB as an immutable data store

For the easy querying I would guess?

It'd also be neat if one can chose different storage facilities for different data entities. For instance, some sensitive data must be stored in sessionStorage which means it's erased when the logged in user closes the session. Putting such sensitive data in indexeddb leaves it accessible to other users on the same machine.

This is an excellent idea. Could you open a separate issue for this request so it can be tracked and committed against?

Many thanks for your comments and questions. 👍

from forerunnerdb.

Thanks for the quick reply. I did open a separate issue with even more points/ideas:
#36

from forerunnerdb.

This may get long, but here's an explanation of how I planned to use ForerunnerDB:

I work on an application where there is a large set of data, we have a set group of (very busy) users that each owns a portion of the records and are expected to manage them weekly (~25k per user). The number of records will be growing substantially in the near future (~250k per user).

We are moving towards MongoDB from Oracle, because of the complexity of the searches, to make managing data-sets possible for our users. We're using node with mongoose on the server side, React+Flux+webpack client-side. Many operations on the UI need to have much or all of the data-set loaded. Paging / executing many queries is something we are trying to get away from, as the user changes search criteria frequently and needs to reload parts of the same data-set over and over again.

We have classes written to query the mongoose models. Forerunner looks (mostly) compatible, so it would be a great solution for us to have a client-side API to query already-loaded data when a search changes. The rest of the code would remain common between the server and client. A mongoose (or similar) compatible API would mean the only difference between client and server would be loading db.js vs db.web.js for server/client -- which webpack handles for us.

An example code snippet:

FooDAO.js

/**
 * Used by both client and server.
 * Server loads Foo.js, client loads Foo.web.js
 */
import Foo from './Foo';
export function findAll ( criteria ) {
    return Foo.find( criteria ).exec();
}
export function findOne ( _id ) {
    return findAll( { _id } );
}
export function update ( record ) {
    // ...
}
// ...

Foo.js

/**
 * Server side db access to Foo collection
 */
import mongoose from 'mongoose';
// ...
// ...
export default mongoose.model( 'foo', fooSchema );

Foo.web.js

/**
 * Client db access to Foo collection
 */
import forerunner from 'forerunnerdb';
// ... data already available ...
export default db.collection( 'foo' );

As you can see, with a few minor changes, we could easily plug in Forerunner and FooDAO wouldn't have to know the difference.

from forerunnerdb.