RxDB – a real-time database on top of PouchDB
The concept or RxDB, being able to iterate observables of your change stream, is great.  Centering on schemas and typescript is as well. The broadcast channel based leader election also solved the common issue with Pouch where you can’t respond to real-time changes and update your UI if a separate tab was watching too.<p>It’s wise of them to also support pulling data from GraphQL. I built the first version of NoteBrook on top of couch/pouch, and the biggest pain points were:<p>1. Pouchdb was before async/await and typescript. The typings can be inconsistent, and it’s very difficult to properly manage the lifetimes of local databases because of the promise chaining.<p>2. A database technology for Real time replication Needs ACLs on a per-document basis. I built provisioning scripts to manage separate databases per user, as suggested, and it’s very cumbersome. It prevents me from lots of data sharing models like promoting one record to public view, or sharing a record with another user in a different tenant.<p>3. Personally I feel that the naming / marketing of the product is poor. It does not feel professional ( couch, futon, fauxton, pouch, couchbase) do not feel like professional grade products I can depend on to run a business.<p>I think it would be good for RxDB to support its own backend technology and move away from PouchDB, and in the meantime, de-emphasize the relationship with PouchDB. The RxDB product doesn’t require you to use PouchDB and at this point it’s got a lot of buzz around it and doesn’t need that tie to PouchDB to continue.<p>I feel an ideal library would offer a real-time and offline client db, user auth, and billing, tied to a backend database of my choosing (eg. Postgres, MariaDB). The data layer should allow me to specify the durability requirements of each write (down to the specific entity type) and enforce an atomic commit on all related records in one transaction at the level of the most strict entity in the commit. It should be trivial to shard because the syncing protocol the clients use itself should be available to the server. Multitenancy should be built in. It should support real-time ephemeral in memory data for collaboration/chat scenarios, with optional durability that’s eventually consistent. Schema definitions and migrations should be built in to the product.<p>If you have similar ideas and are interested in working with me on this project, or hearing more, drop me a line.