Rxdb: A reactive database where you can subscribe to the result of a query
1–10 of 126 posts
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#2What is the time complexity of receiving a notification?
Are there triggers that run on every update on the dataset?
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#3Having 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.
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#4Having 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.
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 :-)
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#5Having 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.
There is a limit on what data can be replicated with the client.
For a simple chat-app you can replicate all messages of a user. But you would never replicate the whole state of wikipedia to make it searchable.
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#6Having 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.
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 work.
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#7I'm not sure why you would use this over something more battle-tested like RethinkDB which was also built with this use-case in mind.
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#8I'm not sure why you would use this over something more battle-tested like RethinkDB which was also built with this use-case in mind.
Because rethinkdb development has ceased? Last release was in 2017.
Is there still maintenance?
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#9I'm not sure why you would use this over something more battle-tested like RethinkDB which was also built with this use-case in mind.
RethinkDB is not offline first. It runs queries on the server-side, not on the client.
There is horizonDB which can replicate with RethinkDB but the project is dead with no commits since the rethinkdb company gave up.
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#10Having 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.
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.