That’s a good question. I suppose it is really a performance question so everything must be based on the expected volumes. I am not sure. I have been trying to think this through.
Hypothetically, let’s say you have a social/discussion/chat app. Users log-in via presumably HTTP Request (submit their password and username, validate from database), and are generated a token and websocket connection. At this point, we will have one main GenServer based module I think per user just to manage their connection and server requests. Token is sent to the user and can be stored in that GenServer as well.
I guess at that point we don’t really need to be continuously checking or requesting their token anymore (while WebSocket is maintained, we can trust that they are still “them” I believe (?)). But we would want to check the token periodically to see if it expires (can check the one in the main user connection GenServer we have as it is the same as their now client-side token).
Websockets would be the server bottleneck to design around then. According to this thread we could hypothetically sustain between 60K and 2 million web sockets per server.
You could limit the token checks by having the user connection’s GenServer track also in state “last_token_check_date_time” and check that against current date time, then only revalidate it if difference is more than x amount of time (say 1 hour at most often).
If so, in a maximally performing and optimized server, with max user load, you could be re-validating 60,000-2,000,000 tokens per hour. With more or less load at different times of that hour depending on when in the hour people randomly signed in and got their token.
Am I generally understanding all this correctly? Is this reasonably how it could work? Thanks for any ideas or conjecture.
