PouchDB was way ahead of its time, and I'm just now coming around to how crazy cool it was and is compared to most other tech in its space.
He made a great deal of positive impact on technical areas I care about. Rest in peace.
PouchDB was way ahead of its time, and I'm just now coming around to how crazy cool it was and is compared to most other tech in its space.
He made a great deal of positive impact on technical areas I care about. Rest in peace.
Everything worked fine, and was cool to launch something like that since I'm not a mobile developer by any measure. But PouchDB required using CouchDB for the syncing, which was both the first document DB we deployed in our production infrastructure, and the only use case for having CouchDB at all, so we didn't have lots of expertise about it.
I think managing CouchDB ended up being the biggest maintenance hassle at one point, as it was kind of an extra piece, compared to the "real" setup that hosted the other production data. AFAIK, there was no experts on CouchDB at the company either.
So I guess in the end if this "frontend sync library" you're want to use also ends up dictating the backend storage/engine, then make sure you can "afford" a completely new and standalone piece for just that. Unless you're already using CouchDB, then it seems like a no-brainer.
Probably today I'd cobble together something "manually" with Postgres and WebSockets/SSE instead if I was looking to do the same thing again.
Just now, almost a decade later, we get libraries like Tinybase and SignalDB.