Hasura does this for Postgres. What are some areas where I'd use this instead?
RxDB is offline first. You can still query your data even when the user has no internet. Hasura will not make your app workable without a stable connection to the server.
Rxdb: A reactive database where you can subscribe to the result of a query
101–110 of 126 posts
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#102Having 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.
In short, server data is more normalized than the data client needs. As you get closer to view layer, your data gets denormalized further and further. Client-server interaction sits somewhere in the middle to both minimize the bytes-over-wire as well as the round-trips to the backend to get up-to-date.
Take a look at GraphQL, its central promise is to let client choose what's the optimal data it needs (that often denormalized through nested GraphQL queries), and send it in one batch.
It is not to say there shouldn't be a simple replica. It is just if we want it to be a simple replica, we should have a server-side mirrored some-what-denormalized representation rather than just the raw server-data models.
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#103Earlier quoted context omitted.
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.
I actually used Firebase at the start but this implementation is so that we can migrate 100% to Postgres. I agree though, Rethink is awesome
Just out of curiosity, are you moving off of Firebase because of technical limitations, or because of pricing?
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#104General 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?
The ideal case is that the DB can work out the difference in the subscribed query caused by the DB update so that the front end can make changes incrementally and doesn't have to rerender the entire list/table.
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#105Earlier quoted context omitted.
I actually used Firebase at the start but this implementation is so that we can migrate 100% to Postgres. I agree though, Rethink is awesome
Just out of curiosity, are you moving off of Firebase because of technical limitations, or because of pricing?
Mainly because I want to keep my team small so it’s easier if we all commit to Postgres. But We also hard a hard time with Firebase’s filtering on sub collections (for their new Firestore)
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#106Anyone know how this is different from the reactive query layer that Meteor built on top of Mongo?
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#107You 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…
I think you have not understood what RxDB is. It is a client side database. It works also when the client is offline. It does not need a stable internet connection over a websocket. Your example is similar to RethinkDB and others. A websocket streaming json.
A more common solution includes using Datascript[1] as the client side DB and then using something like Posh[2] or Datsync[3] to handle query/pull subscription changes.
[1]: https://github.com/tonsky/datascript
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#108I 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…
There is a big difference between the changestream of many SQL and noSQL databases, and what RxDB does. Having a stream of changes is useful but not the whole solution. RxDB is capable of using single document changes of a stream and recalculate the new results of an existing query. This saves you not only much IO performance but makes developing much easier. See https://rxdb.info/query-change-detection.html
I would love to use this just for the offline and query change detection capabilities alone - but the latter is currently beta and disabled by default. Is there a reason for that?
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#109Earlier quoted context omitted.
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.
I actually used Firebase at the start but this implementation is so that we can migrate 100% to Postgres. I agree though, Rethink is awesome
Make this good enough and you could very well cut into a huge chunk of Firebase's business model.
I'd seriously love to have query subscriptions, especially if the library is robust enough for use on mobile.
Ine large differentiator of Firebase's DB offerings is the subscription functionality, mobile and web, but using that means buying into NoSQL. A proper subscribable SQL database would be amazing.
Of course the conflict resolution on writes, and the local caching is another key benefit Firebase offers. Not sure how that could be done with a real relational DB!
Re: Rxdb: A reactive database where you can subscribe to the result of a query
#110Earlier quoted context omitted.
So it's not really realtime... No ? I noticed an instant downvote. It's not the first time i see this behavior on rxdb comments.
The definition of realtime is vague so saying that something is "not really realtime" just because it is not "realtime computing" is wrong.
In fairness it was a bit pretentious of whoever decided to call it real-time which was a word with a specific meaning and a very hard earned reputation. 'Live' might have been better.