21–30 of 126 posts
Meteor do this since inception with MongoDB on server and MiniMongo in client.
RxDB does exactly one thing which is being a client side database. You are not tied to a specific ecosystem or backend database.
We used this for our mobile apps and the experience was pretty awesome. The ability to live observe both individual objects in the dB and results of queries makes building reactive UI’s a very pleasant experience.
I'm not doing field projects anymore but knowing this exists would have helped me tremendously in the last few years.
Thanks for sharing!
Earlier quoted context omitted.
How would that work, with, say Twitter? Copy all tweets ever to each browser? I mean, that's why it didn't catch on right :-) It's hard :-)
Same way you scale replication for any server, by sharding and only replicating the shards you care about. The "shard" could just be that users own feed in this case. Then you get offline for free where user adds a tweet and it appears immediately, replicating back to server when he goes back online. The server replica side will need to be a lot more complicated to deal with broadcasting but I don't see why it won't…
Why not just load what is needed and hydrate the data over time? What about datasets where you need pagination/ordering etc. And the only way to guarantee order is to pull the whole set?
It basically registers itself as a fake replica server so that it can get updates from the master (like binlog in case of MySQL) and then it forwards those updates to Kafka. The possibilities are endless what you can do with those updates as Kafka consumers.
Having client state just be a replica of server state solves so many problems I don't understand why the concept never caught on. Pouchdb/couchdb are still the only ones doing it afaik. Instead we have a bajillion layers of CRUD all in slightly different protocols just to do the same read or write to the database.
PouchDB is mentioned a couple of times, including one “PouchDB compatible” mention. Wondering what unique use cases RxDB supports?
Earlier quoted context omitted.
When your data is public and immutable, this approach is very pleasant. The client becomes just another caching layer and worst case it's presenting a historical version of the truth. You can even extend this across tabs with things like local storage. This breaks down quickly once you have data that could become private or mutate rather than append.
This what stopped me exploring couchdb further. The "one db per user" model for private data made using other features like views etc more difficult when you have to upgrade,edit,remove them. Mutability wasn't really a problem, either present the conflicts to user and pick one or write code to merge if possible.
https://docs.hasura.io/1.0/graphql/manual/subscriptions/inde...