Thoughts on PouchDB/CouchDB architecture

[nolanlawson]

I was asked by @RPallas92 to provide some feedback on the design of the PouchDB/CouchDB sync, so I thought I'd respond publicly in a GitHub issue.

First off, if you want to avoid PouchDB slowing down the UI due to worker operations, putting it in a web worker is currently the best approach. Unfortunately Chrome and Firefox's IDB implementations still do quite a bit on the main thread (Edge's and Safari's don't, FWIW).

Second, I'm usually not a big fan of the "online first" model (i.e. prefer network to cache, fallback to cache only when offline), mostly because it's impossible to determine whether a user is truly "online" or not (e.g. consider captive portals, lie-fi, DNS failing, etc.). So you have to resort to making a request, waiting a looooong time to see if it succeeds or not, and only then falling back to the fast offline cache.

However, if you have to do it, then you could do a sort-of Promise.race() like p-race which runs both local and remote at the same time and returns whichever one returns faster. You can do this using two different PouchDB objects - one via HTTP, the other via local (or worker-pouch if you want to make sure it runs in a web worker).

Third, another option is to only run your PouchDB sync inside of the web worker, and then do your read accesses from the main thread. This should work although I admit I haven't tested it in a real app and there may be weirdness because currently the only way for PouchDB to signal sync changes is using localStorage (yeah, I know) which only allows for inter-tab communication, not worker-to-main-thread communication. However in principle IDB is asynchronous and transactional so the data between the main thread and the UI thread should be in sync – you just might not get change notifications in the main thread if data is written in the worker.

Does that answer your questions? BTW keep in mind that a lot of this is unexplored territory; if you are running this stuff in production then you are in the best position to run benchmarks, find opportunities for improvement, etc. Let us know! 😃

[jkleinsc]

Thanks for the thoughts @nolanlawson! As you know this is something I am still trying to figure out. Ideally I would like to support multiple approaches so that implementors could choose a strategy most applicable to their environment (with a default of the most efficient strategy).
For example in a local hospital network install, online-first might be the best because you wouldn't have to wait for syncs to share data across devices.
On a precarious/lie-fi/remote location offline first would make the most sense.
It is fun living on the bleeding edge 😃 !