[mertnesvat]

Congrats on the launch! I'm also a fan of glitch so congrats on that good job too.

Just out of curiosity have been reading the engineering part and came across with below for not using websockets, confused because debounce and throttle is mainly used to avoid many updates over sockets so it's very well known problem for reactive programming

( https://pketh.org/how-kinopio-is-made.html )

> You might be wondering, why don’t you just update the database with websockets instead of relatively slow API requests?

> The problem with saving data with websockets is that they’re too fast. Authenticating that many messages per second and writing them to disk would be really inefficient. E.g. If you’re moving a card from position x: 20 to x: 420, Kinopio will use websockets to broadcast many updates during the move: moving card x to 21, moving card x to 24, moving card x to 28… potentially hundreds of messages.

[pketh]

That's a good point, and I should look into that (it's been a while since I touched that part of the codebase). Off-hand my guess is that the other reason I handle api requests separately is because I can group multiple actions into a single request more easily, which isn't something I need to do with websocket streaming

[tough]

You might find supabase realtime an interesting read too?

https://supabase.com/blog/2022/04/01/supabase-realtime-with-...

other CRDT/WS implementations/threads https://github.com/yjs/yjs https://news.ycombinator.com/item?id=22039950 https://syncedstore.org/docs/sync-providers/