I'm facing a challenge understanding how to program a web version of a card game that is completely stateless.
I create my object graph when the game begins and distribute cards to PlayerA and PlayerB so I lay them out on the screen. At this point I could assume that HTML and the querystring is what holds at least some of my state and just keep a snapshot copy of the game state on the server-side for the sole purpose of validating the inputs I receive from the web clients.
Still it appears to me that the state of the game is by its nature mutable: cards are being dealt from the deck, etc.
Am I just not getting it? Or should I just strive to minimize the side-effects of my functions to the objects that I take as my input? How would you design a stateless card game?
Best Answer
It's not state what causes problems in scalability but keeping up with state.
I don't know if you are to design a REST interface, which is about state transfer, not statelesness. Statelesness would mean, that doing the same action twice has the same result.
This doesn't even apply to HTTP. If you do a DELETE request twice, the second one is pretty much supposed to fail.
In case you're developing an HTML-based game, nothing stops you to maintain state on the client in JavaScript.
In servers, the problem with state is usually its mutability:
Also, there's a problem with concurrency:
And finally, there's a problem with storage&retrieval and failure:
So, state is normal. It's part of life. Computers are about interactions: a non-interactive computer is called book or newspaper, or rather, a poster (as a book has both open and closed states). Interaction changes state. While we try to minimize maintenance of state, we can't avoid it by nature.