If you're curious about me or about the process of designing/creating, these blog posts might be helpful:
- https://pketh.org/how-kinopio-is-made.html
If you're curious about me or about the process of designing/creating, these blog posts might be helpful:
- https://pketh.org/how-kinopio-is-made.html
https://pketh.org/how-i-build.html
let me know if you have other Qs
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.
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/
kinoko (mushroom) +
Pinocchio
I would rethink your metaphor about organic software[0].