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

71–80 of 126 posts

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

#71

Post by bananocurrency »

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.

Backwards. That's reality. Do you also build applications with any kind of authorization and just hope users don't do anything wrong? Sure is how users behave most of the time!

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

#72

Post by jtmarmon »

You can do this in datomic! I made an end-to-end proof of concept of this using datomic and websockets. The client can open a websocket and subscribe to a query and then the server will react to changes in the database and automatically update the model and therefore the UI (no eventing code required).

Demo vid https://v.usetapes.com/85knuAPruB Longer description in github readme https://github.com/jtmarmon/hackerthreads

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

#73

Post by dustingetz »

jtmarmon wrote: post #72

You can do this in datomic! I made an end-to-end proof of concept of this using datomic and websockets. The client can open a websocket and subscribe to a query and then the server will react to changes in the database and automatically update the model and therefore the UI (no eventing code required). Demo vid https://v.usetapes.com/85knuAPruB Longer description in github readme https://github.com/jtmarmon/hackerthr…

Also see https://github.com/metasoarous/datsync - note that this project stalled out due to technical challenges, though i hear they're stealthily working on it again and coordinating with the Declarative Dataflows project https://github.com/comnik/declarative-dataflow

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

#74

Post by dizaime »

dsun180 wrote: post #21
dizaime wrote: post #13

Meteor do this since inception with MongoDB on server and MiniMongo in client.

Yes, mongodb and meteor and minimongo do something similar but with much more restrictions on what you can do. RxDB does exactly one thing which is being a client side database. You are not tied to a specific ecosystem or backend database.

Yeah, with RxDB, we are tied with RxJS, PouchDB and CouchDB.

Anyway, database is hard, opensource is great. We love them both, RxDB or Meteor.

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

#75

Post by rch »

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…

Did you evaluate gRPC or gRPC-Web when considering your websockets implementation?

I'm using gRPC in other languages/frameworks and I'd really like to migrate one of those to Elixir in the near future, but I'm curious to know if anyone else has given it a try.

There's a prominent warning on the repo:

https://github.com/elixir-grpc/grpc

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

#76

Post by amelius »

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.

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

#77

Post by s_y_n_t_a_x »

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.

You know that it depends on the situation.

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

#78

Post by sergiotapia »

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.

MeteorJS tried it and failed miserably. It doesn't scale.

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

#79

Post by beaconstudios »

hey, this is great! I've been building my own version of exactly this concept based on an event-sourced in-memory graph for my visual programming environment and it works really well for creating a collaborative editing system. I'll be investigating this project now to see if I can't use it instead of my hand-rolled solution.

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

#80

Post by beaconstudios »

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.
Post reply on HN