Using socketio adapter as a store is a rather undocumented feature, which is used internally. So not entirely my idea 😉
And we do not use constructor for storing data, as we need persistent storage between users across a single room. With a constructor you will be saving info for each user separately (which is not intended here).
Yes, you can use global variable to store all the information about the room and its users. But using this solution, it won't be secure (as info about all rooms are exposed to the user, yes you can make it better by adding sanitizations and read protects yourself) and second it won't be scalable (as with sockeio-adapter case; using a redis adapter is just a matter of plugging in redis initializer object, and boom now you have storage in an ACTUAL DB, which can be accessed via multiple socketio nodes and hence more scalable)
What is the reason to treat adapter as store. Is it just your idea or some standard? Why not to store data in constructor?
Using socketio adapter as a store is a rather undocumented feature, which is used internally. So not entirely my idea 😉
And we do not use constructor for storing data, as we need persistent storage between users across a single room. With a constructor you will be saving info for each user separately (which is not intended here).
Yes, you can use global variable to store all the information about the room and its users. But using this solution, it won't be secure (as info about all rooms are exposed to the user, yes you can make it better by adding sanitizations and read protects yourself) and second it won't be scalable (as with sockeio-adapter case; using a redis adapter is just a matter of plugging in redis initializer object, and boom now you have storage in an ACTUAL DB, which can be accessed via multiple socketio nodes and hence more scalable)
Really thank you for your exhausting answer