We have been working on a ticket to diagnose why the OpenLMIS-UI is crashing in the Malawi implementation, and while we are not 100% sure we have found all the reasons for the UI crashing, the primary issue we have been able to reproduce is that the way we are loading and caching large data from OpenLMIS Services is causing large performance issues. The root cause is that the browsers local storage is synchronous, which locks up the main thread, and then eats up memory causing a case condition. The solutions is to switch to using IndexDB which is built into Chrome and Firefox web browsers.
Please give me feedback about which library we should use to wrap IndexDB (because the native syntax and error reporting is buggy across browsers)
I’ll admit that I love PouchDB (and CouchDB). I think PouchDB is a good long term approach because its a lazy datastore, so we won’t need to worry about deleting all locally stored data on an upgrade or making a DB migration plan (we can just let Javascript do its untyped weird things)
On the other hand, Dexie.js is under half the size of PouchDB (16kb vs 45kb gzipped) and I think its a totally acceptable strategy to delete cached data when updating the UI
Imho the 30kb isn’t a big deal, since it’s just a one time download (the lib is cached right?). I’m pretty sure we still have API responses that are larger.
I would go with the lib you feel is a better fit - which as I understand is PouchDB.
We have been working on a ticket to diagnose why the OpenLMIS-UI is crashing in the Malawi implementation, and while we are not 100% sure we have found all the reasons for the UI crashing, the primary issue we have been able to reproduce is that the way we are loading and caching large data from OpenLMIS Services is causing large performance issues. The root cause is that the browsers local storage is synchronous, which locks up the main thread, and then eats up memory causing a case condition. The solutions is to switch to using IndexDB which is built into Chrome and Firefox web browsers.
Please give me feedback about which library we should use to wrap IndexDB (because the native syntax and error reporting is buggy across browsers)
I’ll admit that I love PouchDB (and CouchDB). I think PouchDB is a good long term approach because its a lazy datastore, so we won’t need to worry about deleting all locally stored data on an upgrade or making a DB migration plan (we can just let Javascript do its untyped weird things)
On the other hand, Dexie.js is under half the size of PouchDB (16kb vs 45kb gzipped) and I think its a totally acceptable strategy to delete cached data when updating the UI
As I’m new to the whole browser DB concept I would pick up the db you have the most experience with.
···
On Wednesday, September 13, 2017 at 8:04:58 PM UTC+2, Nick Reid wrote:
Dear Dev (and other opinionated people)
We have been working on a ticket to diagnose why the OpenLMIS-UI is crashing in the Malawi implementation, and while we are not 100% sure we have found all the reasons for the UI crashing, the primary issue we have been able to reproduce is that the way we are loading and caching large data from OpenLMIS Services is causing large performance issues. The root cause is that the browsers local storage is synchronous, which locks up the main thread, and then eats up memory causing a case condition. The solutions is to switch to using IndexDB which is built into Chrome and Firefox web browsers.
Please give me feedback about which library we should use to wrap IndexDB (because the native syntax and error reporting is buggy across browsers)
I’ll admit that I love PouchDB (and CouchDB). I think PouchDB is a good long term approach because its a lazy datastore, so we won’t need to worry about deleting all locally stored data on an upgrade or making a DB migration plan (we can just let Javascript do its untyped weird things)
On the other hand, Dexie.js is under half the size of PouchDB (16kb vs 45kb gzipped) and I think its a totally acceptable strategy to delete cached data when updating the UI
