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

61–70 of 126 posts

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

#61

Post by rockostrich »

maxmcd wrote: post #59

General question about reacting to database events: It seems like when responding to DB events it would be easy to accidentally create an infinite loop. Is that an issue with this pattern, or is it easy to avoid? Do any of these data subscription tools have safeguards in place to prevent this?

Isn't this the case with any interaction between 2 systems? Between a client and server, you can have logic in the client that reacts to a response from the server that triggers another request to the server.

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

#62

Post by ihrimech »

maxmcd wrote: post #59

General question about reacting to database events: It seems like when responding to DB events it would be easy to accidentally create an infinite loop. Is that an issue with this pattern, or is it easy to avoid? Do any of these data subscription tools have safeguards in place to prevent this?

This is where command and query (with subscribe) must be neatly separated. An event A launches an updates of the DB, that launches the query part to react, then stop. There is the risk of having an infinite loop, if the event A is launched by the query part, which is very related to the behavior of your app.

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

#63

Post by kijin »

azernik wrote: post #54
megous wrote: post #45

Earlier quoted context omitted.

In reality data can't become private again, after being available. You may try to contact all users to delete their copy, but they may not respect that.

That's in theory. In actual reality, if you're making an app that has private data and is not crawled by bots, most of the time users don't save everything that they see.

I think the parent means clients (user agents), not actual human users. As soon as any state that needs to be hidden is exposed to clients, that's a security breach regardless of whether any human eyeballs have seen it.

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

#64

Post by maxmcd »

rockostrich wrote: post #61
maxmcd wrote: post #59

General question about reacting to database events: It seems like when responding to DB events it would be easy to accidentally create an infinite loop. Is that an issue with this pattern, or is it easy to avoid? Do any of these data subscription tools have safeguards in place to prevent this?

Isn't this the case with any interaction between 2 systems? Between a client and server, you can have logic in the client that reacts to a response from the server that triggers another request to the server.

Very true, maybe I'm overthinking it? In my head: If I update full_name from first_name and last_name whenever a user table row changes, if I do this naively I will update the user on every update and trigger a continuous loop of updates.

I have certainly created infinite loops while using React's componentDidUpdate, maybe it's just important to define triggers on single attributes rather than entire database rows.

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

#65

Post by kijin »

nickspicer1993 wrote: post #26
throwaway_bad wrote: post #6

Earlier quoted context omitted.

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…

I attempted something similar on a current project, the problem is with inital data loading. If you are hitting the URL/Page for the first time you are waiting minutes or more for non trivial data sets. 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?

In twitter-like applications, the default ordering is usually just ORDER BY timestamp DESC. You could rely on this default ordering to load the first few dozen items on first visit, and load the remainder asynchronously. Sort of like automatic infinite scrolling.

Of course, users with limited RAM and metered connections won't like that. Which is another reason why it didn't catch on.

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

#67

Post by markandrewj »

kiwicopple wrote: post #39

I have been developing something that provides this functionality for PostgreSQL: https://github.com/supabase/realtime It's still in very early stages (although I am using it in production for my company) It's very similar to Debezium (mentioned in another comment), but it's built with Phoenix (elixir), so great for listening via websockets. Basically the Phoenix server listens to PostgreSQL's replication functionali…

RethinkDB might be another database to look at if this is functionality which you are interested in. My only gripe with doing this sort of thing is that if you offer a public API, it becomes separate to what you are using for the application internally. There are also some GraphQL databases like Prisma that offer this sort of functionality.

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

#69

Post by megous »

kijin wrote: post #63
azernik wrote: post #54

Earlier quoted context omitted.

That's in theory. In actual reality, if you're making an app that has private data and is not crawled by bots, most of the time users don't save everything that they see.

I think the parent means clients (user agents), not actual human users. As soon as any state that needs to be hidden is exposed to clients, that's a security breach regardless of whether any human eyeballs have seen it.

This is true, too, but I meant users, too. It's all too common for users to screenshot things, etc. I see it a lot of the time on Twitter for example. You can delete tweets, but oftentimes it's pointless. But I also regularly see my gf taking photos with her phone of various apps she uses on her notebook, just to have the info around on her phone. I suspect it's pretty common, because it's much more low-tech then saving pages or API scraping.

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

#70

Post by assface »

silasdavis wrote: post #8
venantius wrote: post #7

I'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?

"Is RethinkDB dead?"

https://github.com/rethinkdb/rethinkdb/issues/6747#issuecomm...

TLDR: They are hoping to announce a revival in the near future.

Post reply on HN