Clojurians Log v2

thanks!

@mail985 ^

I am currently looking to use PouchDB in a CLJS project and stumbled on this from searching "CouchDB" here in Slack. Very cool! I probably would have written a wrapper like this myself had I not found it. > Hipflask just retries your swap function with the latest data when there's a conflict. So if two people increment a counter at the same time, both increments actually happen. Interesting—am I reading this right to mean that it's essentially last-write-wins? > NyanCAD I know nothing about circuit design (or hardware generally), but this looks like a really neat piece of software 🙂.

I'd be curious to hear if you've found any sharp edge to PouchDB for this kind of use case. It seems so well-suited to the modern, offline-first, realtime-sync sort of application that I'm surprised to have not seen it used more (or heard about its limitations/gotchas). The main caveat I've heard is that initial syncs can be quite slow. Is that true in your experience?

One other question @pepijndevos (and I do apologize for the deluge): I notice in your repo's cookie counter example, you've got an interval calling .sync every 5 seconds. I assume that's not necessary if you call an initial call to .sync with :retry and :live as true (like this: (.sync local-db remote-db #js{:live true :retry true}))? At least, that's my reading of the PouchDB docs, but was curious why you did it like that.

Ohi!

It's last write wins if you just assoc a document. If you apply a more intelligent update it will retry the update if there is a conflict

It has been surprisingly smooth. It's such a nice match for atoms. There are a few minor browser and json limitations like string keys, maximum parallel connections,etc

Maintenance is a bit slow but that seems not unusual in clojure either

Initial sync is slow if there is a lot to sync so that's a matter of app design

The cookie clicker example is years old at this point so I don't recall but what you say sounds right