Replies: 1 comment 1 reply
-
Thank you for the info. The real issue is here: I have a lot of ideas and technology to improve this and also of the knowledge to implement it. But what I don't have is time for this. This is still a hobby project and maintaining and improving the current application's state is time consuming enough and that doesn't include all the feature requests in backlog 😅 Changing the complete architecture is a very time consuming tasks. And before changing the tech stack, I would first try to change to a "command" based architecture. Currently "set initiative of brute to 56" will just change the local game state which is then send to every device. Instead, it would be much better to just send the information what changed and then change the game state on every device by this information. But still, this all just would take too much time currently 😞 |
Beta Was this translation helpful? Give feedback.
-
Vulcan seems intended for use in applications exactly like this one: Multiple people making adjustments to shared state on their local device where a requirement for solid/responsive state management on the server side can cause hiccups or delays. Vulcan integrates the concept of CRDTs to the well-understood tech of SQLite.
Beta Was this translation helpful? Give feedback.
All reactions