Support webSQL/IndexDB for client-side persistence + Documentation

[Naman Goel]

Since ForerunnerDB has the same query language as mongoDB, simple usage is very straightforward.

However, some of the the newer features — client-side persistence with local storage aren't documented at all. It is a very important feature for me, and I would like to know how it works. Do I need to manually set-up the database each time, or does it real from the local storage automatically.

Another important factor is that local storage is synchronous and can be a performance bottleneck. It would be much better if ForerunnerDB could persist to WebSQL and IndexedDB instead. Mozilla's great LocalForage project seems like a good option to make it work with minimal changes. But it would make .persist an asynchronous operation.

Ideally, LocalForage should be an optional dependency for async storage.

Thoughts?

[Rob Evans]

Sounds like a good idea!

The persistence will be documented, apologies for the hole in the doc on that, I've spent a good chunk of time documenting the operators etc.

Just an FYI, you can persist any collection like this:

db.collection('myCollection').save();

Then when your app loads you can do this:

db.collection('myCollection').load();

I am in the process of creating a todo app tutorial which has persistence. It's not linked to yet but you can see an early version of the page (unfinished) here: http://forerunnerdb.com/tutorial/todoList.html

If you skip to step 7 you should see how it sets up the load() and save() calls. I'll be putting some more effort into docs this week and will investigate the storage options you mentioned as well.

:)

[Rob Evans]

Use of localforage for persistence is now on the roadmap for version 1.3.0 (see dev branch for updated roadmap).

[Naman Goel]

Thanks for the quick response! I'm looking at the code and I notice that you already have support for callbacks for the save and load methods.

I want to start using forerunnerDB right now. I hope you're open to pull requests.
Also, I want to know a little big about how ready the project is for production.

I'll try to add the documentation for the persistence as well.

I'm assuming the pull request should go into the dev branch for now. And I'll try to follow the style of the other code in the repo. Eventually, it would be nice to have some contribution guidelines.

[Rob Evans]

Thanks for the quick response! I'm looking at the code and I notice that you already have support for callbacks for the save and load methods.

Yes it should be pretty easy to plug in localforage, I had a quick look when assessing the difficulty from your last message and it looked like about 2 hours max including creating unit tests :)

I want to start using forerunnerDB right now. I hope you're open to pull requests.

Always, community engagement is a very good thing.

Also, I want to know a little big about how ready the project is for production

We are using ForerunnerDB in production on a site that has 6 million active users to handle data. It is a very data-intensive application and also includes realtime data updates coming from Node.js through Faye, into Forerunner and then the DOM is updated automatically.

I'll try to add the documentation for the persistence as well.

Thanks, any help in the doc department (or any other) is most welcome!

I'm assuming the pull request should go into the dev branch for now.

I think if it's doc-related and relevant to the current master branch version then it can pull-request against master. If it changes code then yes, I think dev is the way forward.

Just so you know, when updates are made, unit tests to give coverage to those updates need to be run and pass before the feature can make it to the master branch.

Eventually, it would be nice to have some contribution guidelines.

Agreed. I'll add it to the roadmap :) thanks for your time and input, it is always welcome 👍

[Rob Evans]

I should mention that the iOS version is still an alpha product and not production ready at all. The stuff in the server folder should be considered the same way.

I think I will remove those from this project and create separate ones for those going forward as they are totally optional and just bloat the download right now.