As a web developer I'm used to a straightforward flow where all interactions typically correspond to a database read/write and the life-cycle corresponds with a single request.
As a learning exercise I wanted to write a basic multiplayer card game and realized I have a lot of confusion about where to best store active game state.
- Create a global state object
- Create an active
- Push it to an array in the global state
- Perform actions on this active
gamein memory, broadcast new state to frontend via websockets
- When the active
gameis complete, write the results to a database for persistent storage
- Remove the active
gamefrom the state, thus freeing memory?
- Is this a reasonable solution or is it a bad practice? (global variables, memory management, state loss on process crash/restart etc...)
- Would it make more sense to set up a redis server for handling temporary state?
This is quite different from a frontend perspective where redux/vuex makes handling state a straightforward task, and from what I've read, it is desirable for the backend to be 'stateless' - it just seems weird to me to read/write to a database for things that don't require long-term persistence.
Edit: I also know firebase could be a very suitable solution, I just prefer to avoid vendor lock-in if possible.