Basil.js – Smart persistence layer
github.com
Basil.js – Smart persistence layer
1–10 of 24 posts
Re: Basil.js – Smart persistence layer
#2That seems promising. Would be great to have FIFO and LIFO storage mechanism here like in redis!
Re: Basil.js – Smart persistence layer
#3Synchronous 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.
Re: Basil.js – Smart persistence layer
#4Synchronous 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 c…
This. I recently moved to localForage[1] and have been mostly satisfied so far. Thanks Mozilla!
Re: Basil.js – Smart persistence layer
#5Synchronous 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 c…
This. I recently moved to localForage[1] and have been mostly satisfied so far. Thanks Mozilla! [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)
Re: Basil.js – Smart persistence layer
#6looks great!
Re: Basil.js – Smart persistence layer
#7Synchronous 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 c…
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..
Re: Basil.js – Smart persistence layer
#8That 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?
Re: Basil.js – Smart persistence layer
#9What about lawnchair?
Re: Basil.js – Smart persistence layer
#10That 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.