Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rxdb: A reactive database where you can subscribe to the result of a query

github.com

Post reply on HN
Print view View original

91–100 of 126 posts

Re: Rxdb: A reactive database where you can subscribe to the result of a query

#91

Post by ralusek »

gwbas1c wrote: post #58
throwaway_bad wrote: post #3

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.

> Having client state just be a replica of server state solves so many problems I don't understand why the concept never caught on. As soon as your server state is larger than whatever your client can handle, the whole metaphor breaks down.

I'm assuming that the client state would be a lazy representation of the back end state, that only pulls data as needed. The result being that local and server state must both be treated only as asynchronously accessible.

Re: Rxdb: A reactive database where you can subscribe to the result of a query

#92

Post by anarazel »

kiwicopple wrote: post #87
pbowyer wrote: post #83

Earlier quoted context omitted.

Interesting, thanks for sharing how you're doing it. Is there any mileage in doing this with triggers? I have a _very_ legacy system which needs caching adding. Rather than dig through the code to invalidate the cache every time a record is updated/deleted in 20+ tables, I am thinking that being able to listen to the SQL executed and invalidate the cache based on the tables involved would be a clean approach. But not…

Yeah I also used triggers at the start. There are 2 things that this implementation achieve over triggers. 1. Triggers have an 8000 byte limit. I ran against these limits pretty quickly 2. You need to attach the trigger each time you create a new table. With this you can set and forget

There's no 8k limit with triggers? Could you expect on what you mean by that?

One of the motivating factors for not using triggers is that the implied overhead is very significant. By logging changes separately which triggers the write volume is roughly doubled, and the overhead of insertions is much much higher (a lot of fast/bulk path can't be used, the trigger processing needs to be performed).

Re: Rxdb: A reactive database where you can subscribe to the result of a query

#93

Post by kiwicopple »

anarazel wrote: post #92
kiwicopple wrote: post #87

Earlier quoted context omitted.

Yeah I also used triggers at the start. There are 2 things that this implementation achieve over triggers. 1. Triggers have an 8000 byte limit. I ran against these limits pretty quickly 2. You need to attach the trigger each time you create a new table. With this you can set and forget

There's no 8k limit with triggers? Could you expect on what you mean by that? One of the motivating factors for not using triggers is that the implied overhead is very significant. By logging changes separately which triggers the write volume is roughly doubled, and the overhead of insertions is much much higher (a lot of fast/bulk path can't be used, the trigger processing needs to be performed).

Sorry I meant I was using triggers to sent a NOTIFY which has an 8k byte limit.

Very true what you mention about trigger overhead. Also you don’t get guaranteed atomicity

Re: Rxdb: A reactive database where you can subscribe to the result of a query

#94

Post by amelius »

beaconstudios wrote: post #80
amelius wrote: post #76

How useful is real-time data really? For example, HN isn't updating in real time and for me that's fine. If real-time updates come at a ridiculous complexity and performance cost, then is it really worth it? See also Google Wave, which had "real time" as its main novelty, but ultimately failed.

for my project it's very useful for collaborative features. Multiple people need to be able to edit the same graph structures at the same time, which would be difficult to scale out via a notify-and-poll architecture.

I've found that collaborative editing can be very confusing, and prefer a commit/merge step over simultaneous editing. I think all collaborative editing software should at least offer this kind of interface.

Re: Rxdb: A reactive database where you can subscribe to the result of a query

#95

Post by marknadal »

dsun180 wrote: post #50
yc-kraln wrote: post #48

Earlier quoted context omitted.

I read through your whole readme and I still am not able to answer the question: "what kind of project would I use GUN for?" or, even, "what is gun replacing?" I mean, it looks interesting and I would like to play around with it, but I don't understand enough to know what kind of stuff I can build with it.

I tried several times to understand what GUNdb does and how its different or which features it has. I have given up. As far as I can tell it is something between Blockchain, graph-database and sync. I also tried to understand the codebase which is impossible with obfuscated code like this one: https://github.com/amark/gun/blob/master/lib/store.js#L16

Thunderbong's answer is spot on (it replaces Firebase).

Here is a 5min interactive coding tutorial that shows that using GUN is more powerful than reading about GUN. https://gun.eco/docs/Todo-Dapp

For instance, Archive integrated in 1 week.

Notabug first version was built in 1 week with it. (p2p Reddit)

Organization can go a far ways in a short time.

Re: Rxdb: A reactive database where you can subscribe to the result of a query

#96

Post by bayesian_horse »

tehbeard wrote: post #12
koolba wrote: post #10

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.

Yeah, couchdb more or less requires you to replicate data for individual users if you need complex permissions and want the user to access the couchdb directly.

Permissions in general need to be handled by custom reconciliation functions (dropping unauthorized changes) or some kind of nanny system that can react to changes.

For example, imagine blog posts as documents, and a list of comments inside that document. Instead of the user adding/changing the comment list, the user would add a record to a comment request list, and either the reconciliation process or a nanny service checks the requests and updates the comment list.

The much simpler solution of course is to not let the users have any write access to the couchdb and just use a REST API. But then you loose much of the benefits of couchdb...

Re: Rxdb: A reactive database where you can subscribe to the result of a query

#98

Post by bayesian_horse »

skrebbel wrote: post #4
throwaway_bad wrote: post #3

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.

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 :-)

I've heard somewhere that Twitter maintains a copy of all tweets in a user's timeline for that user.

If I had to make a Twitter clone with CouchDB, I would probably have one timeline document per user, and maybe one per day to limit the syncing bandwidth.

Re: Rxdb: A reactive database where you can subscribe to the result of a query

#99

Post by dsun180 »

lessname wrote: post #82

What I personally like about RxDB is that it also works completely offline. However, I don't really understand encryption: As far as I understood, it encrypts on the client side with the db passwort which is sent to the server. Another issue is Authorization and Authentication, I could not find a good solution for me for CouchDB. Couchbase seems to have better solutions for this but the premium plan seems really expe…

No you normally do not send the password to the server. You can ask the user to enter the password when the application is openend.

Authentication is much easier when you use the GraphQL replication. There you are much more flexible on which data you return depending on which user is asking for it.

Re: Rxdb: A reactive database where you can subscribe to the result of a query

#100

Post by dsun180 »

winrid wrote: post #84

Cool. But how is this better than Meteor for building webapps? Meteor would scale better too with Apollo.

I do not think that meteor will scale better then your GraphQL server with whatever database you want to have. With meteor you are bound to a specific ecosystem which is often a pain. RxDB does only one thing, it is a client side database. Everything else in your stack is free to choose.
Post reply on HN