RxDB – a real-time database on top of PouchDB
1–10 of 48 posts
Re: RxDB – a real-time database on top of PouchDB
#2I love the idea of couchdb, but the ecosystem centers too much on pouch, which doesn't have consistent maintenance. If Ibm was smart they'd sponsor it in a big way.
Re: RxDB – a real-time database on top of PouchDB
#3I love the idea of couchdb, but the ecosystem centers too much on pouch, which doesn't have consistent maintenance. If Ibm was smart they'd sponsor it in a big way.
Yes pouchdb does not get the love it deserves. But it is still actively maintained, the last bug I had was timely fixed by the community and merged.
Re: RxDB – a real-time database on top of PouchDB
#4Title probably ought to be "a reactive database". Though, used properly, you should be able to reduce latency it doesn't make any guarantees.
Re: RxDB – a real-time database on top of PouchDB
#5Title probably ought to be "a reactive database". Though, used properly, you should be able to reduce latency it doesn't make any guarantees.
Yes and no. Read "realtime" not like "realtime computing" but like a marketing keyword introduced by firebase which means something like live-replication. https://firebase.google.com/docs/database?hl=en
Re: RxDB – a real-time database on top of PouchDB
#6Looks amazing. I always loved how Rx composes with IO on the client side, this looks like the missing half. I hope it survives.
For people who are soon to be choosing a stack for their projects, please be careful. In 2015, we adopted RethinkDB which had very similar ambitions as RxDB and was open source. Unfortunately, RethinkDB is now abandoned (kinda). Many promising subscribe-able databases are still experimental. If you are thinking long-term, you may want to consider more boring options.
Re: RxDB – a real-time database on top of PouchDB
#7What's the advantage of this over triggers in a relational database? Or even notify/listen in PostgreSQL? (assuming these triggers are connected to the API, of course).
I guess it's probably a matter of scale, but I really don't know.
Re: RxDB – a real-time database on top of PouchDB
#8What's the advantage of this over triggers in a relational database? Or even notify/listen in PostgreSQL? (assuming these triggers are connected to the API, of course). I guess it's probably a matter of scale, but I really don't know.
It runs fully on the client and is offline first. A listener to PostgreSQL will not work when the device goes offline.
Re: RxDB – a real-time database on top of PouchDB
#9The 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.
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:
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.
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.
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.
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.
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.
If you have similar ideas and are interested in working with me on this project, or hearing more, drop me a line.
Re: RxDB – a real-time database on top of PouchDB
#10The 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. It’s wise of them to also support pulling data from GraphQL. I built the first version of NoteBrook…
Actually, the long term plan is to move away from pouchdb. Before the last major release [1] I decided to make RxDB useable with other frontend/backend databases but then found out that I first should refactor some pain points.