3 ms·

That's a timely response and I too have to noticed that CouchDB may not have the best/compatible future. I have an existing product that depends on PouchDB in

That's a timely response and I too have to noticed that CouchDB may not have the best/compatible future. I have an existing product that depends on PouchDB in the client and the replication. I'm not really into the managed db service offerings, I like to have control over it that they rarely offer. My tentative solution for the application is to go with PouchDB on node.js on the backend too.

WorldMaker 5y ago
I like managed DB offerings because most of my projects rarely have the budgets for dedicated Ops people. I'm worried that our infosec folks are about to kibosh IBM Cloud as a dependency on our projects (and when my projects started Cloudant had good Azure support still, sigh) and I'll have to scramble to figure out PouchDB replication endpoints again. I did consider trying to bootstrap "Pouchserver" in an Electron deployed version of some of my apps. It's mostly just too bad that you can't count on Peer-to-Peer discovery to work at all in corporate environments. At this point I have a half-baked notion of trying to build some sort of custom storage replication in CosmosDB. Like I said it's tantalizingly close to matching the CouchDB replication protocol and I keep hoping if I stare at documentation long enough something will click that there will be a really easy "hack" of a solution. I was glancing at the documentation of RxDB's "GraphQL Replication" in case it gave me ideas. It's a huge departure from CouchDB replication, but maybe it is time to assume that CouchDB replication is not going to be easy moving forward anyway. (At least not without an Ops budget for it.)