search

delaneyj / datastar

263 stars 7 forks source link

client sync #25

Open gedw99 opened 3 weeks ago

gedw99 commented 3 weeks ago

Was wondering if we want to have a mechanism to update clients that happen to be looking at the same page URL ?

The idea is that one user is changing some aspect, and when they change it, we want the other users to also see that change.

This is where NATS is pretty cool.

A few examples of where this "pattern" would be useful :

https://data-star.dev/examples/value_select where the models list was changes by 1 user, and other users can then see it change in their drop downs.

https://data-star.dev/examples/infinite_scroll which is read only, but if one of the rows changed ( due to some other user doing a mutation of the underlying data ), all other users would see it.

Why ?

Well one reason is that you get way less Transactions that fail validation rules back in your storage layer.

The other one is for Dashboards where you want real time sync.

delaneyj commented 2 weeks ago

I'll be working on a game server that shows this exact behavior between NATS and Datastar

gedw99 commented 1 week ago

oh great. I really hope that some of the NATS aspects get shown in the Datastar repo as examples, because I think it will help me and others.

I started using Corrosion as my DB with NATS now. It's a CRDT Sqlite DB in Rust with an elegant HTTP API. SO then its very easy to do a "select * ..." as a subscription and just feed it up to NATS and SSE with Datastar

https://github.com/superfly/corrosion

https://superfly.github.io/corrosion/api/subscriptions.html shows how easy it is.

The DB will scale out master master with nothing needed, thanks to the CRDT. It's working well for me.

I am going to write a golang API to consume easily off it and manage the subscription data to make it more robust.