Basil.js – Smart persistence layer(github.com)
github.com
Basil.js – Smart persistence layer
https://github.com/Wisembly/basil.js
11 comments
I would recommend Mozilla's localforage https://github.com/mozilla/localForage. Basil.js takes care of abstracting cookie, session, memory, and localstorage storage options, but localforage provides an abstraction for localStorage, WebSQL, or IndexedDB. With modern applications I find that I often want more storage available. Cookie storage is limited at 4Kb, localStorage (5Mb), sessionStorage (same as localStorage), IndexedDB (50Mb), and WebSQL (50Mb). Localforage will automatically select the best available storage system for the browser. While WebSQL and IndexedDB allow for advanced queries, localforage must cater to the lowest common denominator, localStorage key value pairs. While being restricted to key value pair storage, this is often not a big concern considering how different the WebSQL and IndexedDB APIs are.
Thank you for breaking it down like this. I never saw it layed out ~specifically like this.
Synchronous persistence APIs should be considered dangerous. Often they solve the immediate problem, but when you eventually need to move to an async storage solution (and in JavaScript any significantly complex task eventually becomes async) you are left with code that presumes sync behavior. This makes it difficult to refactor.
Providing an API with callbacks or better yet promises forces you to write future-safe code.
Providing an API with callbacks or better yet promises forces you to write future-safe code.
This. I recently moved to localForage[1] and have been mostly satisfied so far. Thanks Mozilla!
[1]: http://mozilla.github.io/localForage/
[1]: http://mozilla.github.io/localForage/
It might be a little bit "overkill" when you just want to perform storage only on client device no? (Basil aim is not to override backend storage like REST APIs)
That's a good point. The same issue seems to exist with almost every JavaScript function interface. Whether or not a function is synchronous or asynchronous seems to be an implementation detail (at least in theory), but that fact must be exposed in the function interface.
I think the main issue is actually with language design. Callbacks and promises are not decent ways to handle asynchronity in my opinion. Perhaps it could be abstracted away in the language itself in a way that the function interface would be identical for both "sync" and async functions..
I think the main issue is actually with language design. Callbacks and promises are not decent ways to handle asynchronity in my opinion. Perhaps it could be abstracted away in the language itself in a way that the function interface would be identical for both "sync" and async functions..
I came here to say the exact same thing.
Even if you're using synchronous storage, wrap it in an asynchronous API and save yourself a world of hurt later.
Even if you're using synchronous storage, wrap it in an asynchronous API and save yourself a world of hurt later.
What about lawnchair?
http://brian.io/lawnchair/
http://brian.io/lawnchair/
Lol, I made a library a while back that does the same thing (https://github.com/rectangletangle/jSave). Maybe it's a sign that a larger project needs to be started?
So is this wrapper over cookie and localStorage that takes care of browser differences and idiosyncrasies for you? Or is it more than that?
It also ensure you that your usage of localstorage won't ever throw exceptions and break all your thread in the case of cookie-less anonymized sessions
There's a project with the same name out there: http://basiljs.ch/ This made me wonder: how to deal with similar named open source projects? Although the goals of both projects aren't related in any sense it could cause for some confusion...
Do lots of searching before naming your projects, I suppose. Surely he could have used Rosemary.js, or Herb.js, or Bayleaf.js?
or something even remotely related to ... who knows... data storage?
Bah, ridiculous! Clearly you haven't received the memo, all Javascript libraries are named exclusively by dart-board now.
That seems promising. Would be great to have FIFO and LIFO storage mechanism here like in redis!
Why do you need a mechanism for that instead of using arrays?
Instead of getting an array from storage, pushing a new item inside and then storing it again, it could be nice to have directly this small mechaniam built in to avoid this logic in the application.
Hmm, that's true. The library could monkey patch .push (etc.), but it wouldn't support setting the property directly with [index] (until Object.observe is mainstream enough).
Love the name. (For those that don't get the joke, basil is an extremely persistent, almost weedlike plant.) That said, I think an async solution would be better, like localforage.
Great idea. The next progression would be cross browser benchmarks, and perhaps something suitable for browser extensions (unless this already works for that use case).
Maybe I'm being dumb, but I think this could benefit from the inclusion of a Why? section.
looks great!