While I've not dug into ForerunnerDB, it sounds like it is playing in the same space as PouchDB[1]. PouchDB is a JS database that works in the browser or in Node with various back-ends for data storage, syncs with CouchDB (or compatible, such as PouchDB Server) on the back-end, and currently uses map-reduce queries, though there is work in-progress to implement a MongoDB-like query language[2]. (This will match the Mango query language soon to be seen in CouchDB [3].)
Plus I've been really impressed with the development team—responsive to issues, consistent releases, high code-quality. It's a great project!
It is similar to pouch yes, but is more mongo query friendly right now. Also ForerunnerDB includes data-binding which is a pretty useful thing for web app devs.
in one sense it's cool. So congrats on that.
I wonder though - if it's not as good at updating the DOM as other libraries - what is it's real "place" in the ecosystem?
Is it doing more than wrapping over IndexedDB / LocalStorage?
I'd say, a nice wrapper for IndexedDB is a welcome thing (looks like minimongo already does that). And there's a lot of space to grow in that (providing change events, etc).
Maybe I just don't get the value prop?
Maybe the value prop only really shows up when you integrate the data binding? So it's sort of like reactive programming but based on a structured data store, instead of raw JS objects?
> if it's not as good at updating the DOM as other libraries
ForerunnerDB is actually very efficient at updating the DOM, only making changes to the parts of the DOM that link to altered sections of an object / document.
> Is it doing more than wrapping over IndexedDB / LocalStorage?
Yes much more... it includes views, triggers / change events, transforms, collection joins and the obvious big one - data binding.
> Maybe the value prop only really shows up when you integrate the data binding? So it's sort of like reactive programming but based on a structured data store, instead of raw JS objects?
This is correct and because we've been using it in production for some time we would definitely say it makes web app development a lot simpler!
Ooops, sorry about that, rookie mistake pulling a template and using it without going through all the sections properly. I've pulled it from the page... apologies!
Under the hood, it seems [1] to be based on the excellent LocalForage project from Mozilla [2]. It would be nice to acknowledge that on the website somewhere.
Not sure I get that... localforage is a minor part of ForerunnerDB, it's certainly not "based" on it! In fact you can use ForerunnerDB entirely without localforage.
Imagine if we had to acknowledge every different module we pulled in on NPM for every project we wrote... do you do that?
LocalForage has great cross-browser support (automatically switches between IndexedDB/WebSQL/LocalStorage), not to mention workarounds for browser bugs and the ability to store more data than what LocalStorage allows (~5-10MB). It seems like a fairly non-trivial component.
I just think it's nice to give a little credit where credit is due. :) I do see that you mention LocalForage in the changelog, but a shout-out on the site would be cool as well.
Any transaction support? That's one of the big features of IndexedDB, but I don't see anything about it here. Are you doing each command in its own transaction? That's going to be pretty slow for large amounts of data, and you lose the ability to group multiple queries into a single atomic operation.
* For NoSQL, ForerunnerDB sounds interesting. As IndexedDB has a flawed API and slow (using SQLite!) and buggy implementations - without a shim useless.
So usually the point in a database is a central location to keep data, so you don't pass various excels around. Or you might want the rich querying ability of SQL to produce detailed reports.
What is the point in a browser based NoSQL database? Browser persistence?
> Or you might want the rich querying ability of SQL to produce detailed reports.
That is one of the best reasons for a browser based database. Imagine that your web application needs to show a list of users and then allow that list to be filtered with search or by user type or age or whatever. Instead of having to write complex logic to loop your array of user objects that you got back from your server, or ask the server directly, you can instead apply a query to the list you already have on screen and it instantly updates to reflect the query you specified...
This allows you to use an MVC pattern when creating your web applications instead of littering your code with complex locked-in logic that will suffer instant code rot and be generally a pain to maintain after a month or two of development.
While it's usable in node, the only persistence strategies seem to be based on local forage which doesn't seem to support node. So can't save data in node.
We've built it to be compatible with Node but have focussed on browser usage for this version. Our plans (see roadmap in readme) include all the node goodness you'd expect :)
PouchDB also has quite a few useful plugins (full-text search, geospatial queries, peer-to-peer WebRTC replication, etc), runs on the server, and is LevelUP compatible.
Primarily I've been focussed on getting the browser side solid and reliable in production, sync is definitely on the way though. Don't forget that PouchDB is designed to work with CouchDB and not MongoDB so Mongo lovers are somewhat in the cold right now with client-side counterparts.
For MongoDB lovers, PouchDB supports MongoDB-style querying via https://github.com/nolanlawson/pouchdb-find. MongoDB doesn't have the fundamental sync primitives that CouchDB has so I wouldn't expect a similar solution which supports MongoDB on the server.
It includes views, triggers / change events, transforms, collection joins and data binding. Also this allows you to spend more time on interacting with data than worrying about what browser supports what storage. It is also useful even for apps that have no use for storage because looping over JS objects for specific matches in a number of areas of an app will get dirty pretty quickly.
It's really not a wrapper around indexeddb at all. It doesn't even communicate with indexeddb except to save and load data for storage and that is optional. The main use here is for allowing web app developers to be able to load a dataset from a server and then query it dynamically on the client-side, as well as display that data automatically via data-binding.
But that is the point... you don't have to store it in an underlying browser db. It runs as an in-memory store if you don't use an underlying engine. The persistence module is an optional extra and doesn't even need to be included in the library.
Plus I've been really impressed with the development team—responsive to issues, consistent releases, high code-quality. It's a great project!
[1] http://pouchdb.com/ [2] https://github.com/nolanlawson/pouchdb-find [3] https://github.com/cloudant/mango