LokiJS – In-memory JavaScript Datastore with Persistence
1–10 of 31 posts
Re: LokiJS – In-memory JavaScript Datastore with Persistence
#2While "Performance over everything" is obviously hyperbole, I hope they really don't mean it and actually prioritise correctness: that it apparently does actually store and retrieve data suggests that at some level, at least, they do.
Re: LokiJS – In-memory JavaScript Datastore with Persistence
#3> In-Browser NoSQL db with syncing and persisting
Is the syncing part as straightforward as Pouch[1]? I couldn't find anything about syncing on its docs. If a db comes with an easy offline-first and sync-when-possible model with granular permissions, it will be very interesting. Current solutions have (IMHO unacceptable) fixed dependencies on the backend or the architecture.
[1]: https://pouchdb.com/
Re: LokiJS – In-memory JavaScript Datastore with Persistence
#4Awesome, we're now 1 bored developer weekend away from Mumps.JS
Re: LokiJS – In-memory JavaScript Datastore with Persistence
#5Awesome, we're now 1 bored developer weekend away from Mumps.JS
Probably M.JS for clarity ;) /s
Re: LokiJS – In-memory JavaScript Datastore with Persistence
#6> In-Browser NoSQL db with syncing and persisting Is the syncing part as straightforward as Pouch[1]? I couldn't find anything about syncing on its docs. If a db comes with an easy offline-first and sync-when-possible model with granular permissions, it will be very interesting. Current solutions have (IMHO unacceptable) fixed dependencies on the backend or the architecture. [1]: https://pouchdb.com/
I always wondered what the use-cases for PouchDB are.
Who wants to replicate their "whole" database locally?
Re: LokiJS – In-memory JavaScript Datastore with Persistence
#7> In-Browser NoSQL db with syncing and persisting Is the syncing part as straightforward as Pouch[1]? I couldn't find anything about syncing on its docs. If a db comes with an easy offline-first and sync-when-possible model with granular permissions, it will be very interesting. Current solutions have (IMHO unacceptable) fixed dependencies on the backend or the architecture. [1]: https://pouchdb.com/
I always wondered what the use-cases for PouchDB are. Who wants to replicate their "whole" database locally?
There are ways to filter the replication.
Re: LokiJS – In-memory JavaScript Datastore with Persistence
#8What I find fascinating about a tool like this is how simple it is. An in memory store is not very important to me and what I develop. And yet, Im very happy this exists so that it sets a standard for other work in the future.
Re: LokiJS – In-memory JavaScript Datastore with Persistence
#9While "Performance over everything" is obviously hyperbole, I hope they really don't mean it and actually prioritise correctness: that it apparently does actually store and retrieve data suggests that at some level, at least, they do.
MongoDB all over again.
Re: LokiJS – In-memory JavaScript Datastore with Persistence
#10> In-Browser NoSQL db with syncing and persisting Is the syncing part as straightforward as Pouch[1]? I couldn't find anything about syncing on its docs. If a db comes with an easy offline-first and sync-when-possible model with granular permissions, it will be very interesting. Current solutions have (IMHO unacceptable) fixed dependencies on the backend or the architecture. [1]: https://pouchdb.com/
I always wondered what the use-cases for PouchDB are. Who wants to replicate their "whole" database locally?
The Typeform LITE mobile application is built by using CouchDB and PouchDB which means when the application is online, it replicates the users db locally so the performance is great but the even bigger benefit is that when the application is offline, the user can still do the majority of the operations which would be synced once the application goes online again.
So, probably no-one wants to replicate the whole database locally but there is a strong benefit to replicate parts of it for performance and offline-capabilities.
Disclaimer: I was one of two developers on the mobile app mentioned above.