There is a way to only allow the server run on websockets / TCP sockets and idenfity the user by their connection id (provided by socket server) ?
Regards
PD: I'm still reading the documentation to see if there is any example or explanation.
While not really about actionHero, I think your question is about game servers in general:
Folks looking to design a game server coming with experience creating webistes or other REST APIs often make the mistake of thinking they can operate their game servers statelessly as well. I've made this mistake a number of times :D A good rule of thumb is "if your game requires "real time" communication, you probably can't afford to hit a DB on each request". It is vey appealing to try to make your game entirely database-driven (great recovery, no locking problems, etc), but in reality it is often too slow.
The reason I brought up "chat" is that the major pattern most MMOs, shooters, and other "fast" online games use is what I call the "keyframe and diff" method of synchronization. I don't mean "chat" as in two people talking to each other (although it can be used for that), but rather the sever chatting with the client.
Keyframes are large blocks of data that represent the state of the game world at a moment in time. This is, I think, what you have in mind with your `var zone = {}`. This data is large and is usually out of date by the time it reaches the client. Diffs are changes between the state the user got before and now. Diffs are "player #3's health is now 99 or npc #42 is at position [x,y]" These diffs are the type if information you should be sending to your clients as soon as they happen (to help prevent collisions where 2 players conflict, like ending up in the same place).
In actionHero, you can have the "playerUpdatePosition" action re-broadcast any information it receives into a chat room for that realm. This information can then be sent down to the clients, and now no one needs to poll for updates at all. You can create initializers (server-side code that also listens to evens on channels, and you can use them to process NPC movement and other things like player v player activity). You can also create tasks that do some action on the game state every-so-often by once again, broadcasting on these "chat rooms".
While actionHero strives to allow any client to connect to any server and join the relevant chat rooms (thanks Faye!), you will probably end up having only one actionHero node/server processing a realm at a time. You will need to figure out a way to coordinate this between all your nodes, but acitonHero will help you to ensure that getting and sending data will always work for all your clients.
Getting back to databases, you should always back up your games' state (in a non-blocking way) to redis or some other DB, but I would suggest that you don't use it for every client's request.