Earlier quoted context omitted.
That’s great to hear! Are you pubkey? If so you should put that in your profile! I hope you know that I think RxDB is a great lib and going in a good direction! I recommended it to the Supabase team a couple weeks ago. I am less long PouchDB, it feels like an old generation of this tech and not the best way to solve these problems in 2020.
I updated my profile. I do not know supabase, is it similar to hasura? They spend quite some effort [1] to make the RxDB graphql replication working with their backend. Maybe supabase can use a similar wrapper over GraphQL. [1] https://hasura.io/learn/graphql/react-rxdb-offline-first/int...
RxDB – a real-time database on top of PouchDB
21–30 of 48 posts
Re: RxDB – a real-time database on top of PouchDB
#22Re: RxDB – a real-time database on top of PouchDB
#23But is it really "realtime"? I thought something should have consistent millisecond or even microsecond latencies to be called realtime, but it's probably not possible for JavaScript application.
Re: RxDB – a real-time database on top of PouchDB
#24How is this different from Firebase RTDB? And perhaps more importantly, does it address the scalability and consistency issues associated with Firebase RTDB? Google introduced Firestore to Firebase specifically because RTDB has limited usability for larger real world applications that go beyond "sync device state to DB". Even the offline first paradigm is fundamentally flawed in general and certainly when it comes to…
I have no deep knowledge of Firebase RTDB so I cannot do any comparison on that point.
Re: RxDB – a real-time database on top of PouchDB
#25But is it really "realtime"? I thought something should have consistent millisecond or even microsecond latencies to be called realtime, but it's probably not possible for JavaScript application.
Re: RxDB – a real-time database on top of PouchDB
#26Looks amazing. I always loved how Rx composes with IO on the client side, this looks like the missing half. I hope it survives. For people who are soon to be choosing a stack for their projects, please be careful. In 2015, we adopted RethinkDB which had very similar ambitions as RxDB and was open source. Unfortunately, RethinkDB is now abandoned (kinda). Many promising subscribe-able databases are still experimental.…
I agree, I think the move to a more mature state management on the client in general sort of obviated the needs for these databases. Eg if you’re using redux, or mobx, or Apollo, you can cache offline data directly in your state tree, and can define validation functions locally on state transitions to keep your data valid with your business rules while it’s offline. I still feel there’s a space for this tech, but tha…
Re: RxDB – a real-time database on top of PouchDB
#27The concept or RxDB, being able to iterate observables of your change stream, is great. Centering on schemas and typescript is as well. The broadcast channel based leader election also solved the common issue with Pouch where you can’t respond to real-time changes and update your UI if a separate tab was watching too. It’s wise of them to also support pulling data from GraphQL. I built the first version of NoteBrook…
Why can't this be done with a thin wrapper around Postgres pub/sub + triggers?
Re: RxDB – a real-time database on top of PouchDB
#28Looks amazing. I always loved how Rx composes with IO on the client side, this looks like the missing half. I hope it survives. For people who are soon to be choosing a stack for their projects, please be careful. In 2015, we adopted RethinkDB which had very similar ambitions as RxDB and was open source. Unfortunately, RethinkDB is now abandoned (kinda). Many promising subscribe-able databases are still experimental.…
Subscribe-on-update databases are, almost by definition, problematic to use at scale as a generic storage solution. The fundamental problem is that they do not solve many real world problems efficiently enough to warrant the significantly higher running cost. Of course there are exceptions but it'll be hard to launch a MongoDB type of product that uses a subscription only model (see Firebase RTDB and its problems and…
In fact the pull based approach is doing work all the time to process all the polling. A push based approach only does work when needed (when data changes).
I’m not saying it’s not new or hard to scale. I’m just saying objectively that push based is more efficient at least in terms of raw data sent down the wire
Re: RxDB – a real-time database on top of PouchDB
#29The concept or RxDB, being able to iterate observables of your change stream, is great. Centering on schemas and typescript is as well. The broadcast channel based leader election also solved the common issue with Pouch where you can’t respond to real-time changes and update your UI if a separate tab was watching too. It’s wise of them to also support pulling data from GraphQL. I built the first version of NoteBrook…