Yes, I think, except that in AJAX long-polling connection closed after the client receives data and then opens a new connection (?) whereas in SSE the connection is kept open.
Server-Sent Events (SSE) is the new kid on the block in the world of client/server communication. It’s introduced as a part of HTML 5 standard which is not supported by Internet Explorer . So it is not the best option if your application must support legacy browsers.
SSE has two major differences with WebSocket:
The communication is unidirectional
The client/server communication is over HTTP
In SSE an HTTP connection establishes between client and server, similar to Rest API which never closes. Then the server can stream data to the client whenever is needed. But the client cannot communicate with the server over the same connection. The client has to request for any data using the conventional Rest APIs. In other words, SSE is exactly the opposite of the Ajax polling.
One concern I have with the first approach is that database (in my case it is a single MongoDB) size might drastically grow up as it holds data for all users of all apps now and I might hit performance issues.
Well… You shouldn’t need to worry about the row count of your database. Some database systems have caches that alleviate the strain. Column count is something you can control - and it’s always a good idea to make sure you aren’t creating columns you don’t really need.
I’m not a database expert, but I have a lot of experience and time using them. If the users are universal across all apps it would make sense to keep them in the same database. It might even make sense to separate that data from the other data if that’s the only similarity - that is to say there is one account for multiple different games. That would be called an SSO auth scheme.
And yes, of course, user account data will be shared across all apps and will be handle in a separate module (SSO) on a single database, my point mostly was about per app related stuff like the lobby data, player campaigns,…
If it bears no relation to all of the apps it shouldn’t be in the same database. It sounds to me like you want a users database and individual databases for each app - because each one bears no relation to the other.
It would make sense to, yeah. One app for the accounts and one for each app. This way if one app goes down they can still log in and use the apps that aren’t down. And subsequently you can take one app down for maintenance and leave the rest of the services available.
It seems like a cluster-f*ck but it will mean you can pretty much leave the accounts alone once it’s done, and in terms of maintenance your separation will save you from going bald dealing with so much code that doesn’t even relate to one another.
I should probably explain this a little more, too.
Always store files in a file system. Images are a great example of this.
If you rarely pull additional profile data (about me, description, my website, my address, etc) don’t put it in the user object. Put it in a separate object. This way if there is no additional data (the user didn’t provide any) you can just return null (no additional data) and every single row of users isn’t populated with mostly empty columns. You’ve saved yourself pulling x columns of empty data for each user that is queried - and not even needing it most of the time except for when they click the profile page - which is rare in comparison. The profile table will probably receive a single digit percentage of the traffic of the user table.
What about when some client wants to connect to the game server.
Suppose client has already got the ip:port of the game server from the master server and now wants to make a connection to game server.
Should I also give the client a temporary access token to use when connecting a game server? So the game server can also safely authenticate who is being connected, either doing itself by using the shared public-key or by asking from the master server.
The user requests to join with their session ID they got when they logged in.
GameServer checks SID with auth server and accepts/rejects.
If accepted, auth server sets “active game” column to server token.
Their Session ID can only be part of one game. To do that you bind an “active game” column to a user. This stops single users logging into multiple games (account sharing).
Now you know who is connected to what. But you don’t want to keep querying the main server after they have joined successfully. From here-on you can accept the connection as valid.
Send the user back a token from the game-server. Do NOT use the original SID because that’s a password for all intent with ALL permissions. Use that token as a user reference to communicate bi-directionally.
Actually, in my case, all my REST endpoints are stateless (not session based), and every time the user login he gets a newly created JWT token valid for 48H, and from now on he uses this token to make a call to my REST endpoints.
If I got you right this Session ID is something that varies on each login, Yes? for example a random UUID.
And If I understand it correctly the Session ID should be a column in user account table that gets updated every time user login. And the client should use this Session ID to connect to the game server.