Yeah, that is what I like about retrofit, you just write an interface like the controller of the server and call it like it was RMI. you don’t need to implement anything either. If you don’t like RxJava, there are other adapters. I believe you can use Promises as well if that is more your thing.
I am back with another question,
Is it a good idea to use Server-Sent Events (SSE) with my RESTful master server for cases I need realtime communication and to prevent Http request polling. (for example every 10 seconds)
For example when a party invitation request or friend request is made, or when the master server sends a necessary message or showing the realtime status of friends (offline/online/in-game)…
I am not familiar with SSE yet, but I read it is a cheaper solution than WebSocket, and that is an HTTP standard that handles a unidirectional event stream and receives updates whenever the server emits data. (Client can just receive data from server but can not send anything)
Or you think it’s a bad smell?
I am interested to hear your opinion as well.
My personal opinion is that if I wanted to maintain a constant connection - such as chat - or anything that requires real-time updates (over http) I would use a web socket.
If time wasn’t a priority - e.g. updating a forum new post - I would just poll. Every 10, 15, 20 seconds would be perfectly fine for that situation.
Sockets are pretty light-weight and allow you to decide when to send something either way. Polling only allows sending on request.
It depends entirely on how you want it, really. Any mechanism is going to require some kind of throttling.
Reading over it a few times, it sounds like you’re in-game when this is happening.
If this is the case - you want to connect to a primary server using tcp, but not necessarily http. You would create a protocol - such as a handshake agreement and data bundles (request/send) and handle it like a regular socket connection. There’s no need for http unless you want this data publicly available for others to see on a website.
No, we are not in-game yet. The player is not yet connected to the game. Suppose that he is in the “Social” tab and can see a list of all his friends and their status and so on.
All the scenarios I am talking about are about communicating with the master server.
regarding chat, it is an in-game feature and will already be handled by JME Networking in realtime.
10, 15 seconds should be fine for my needs in case polling will not cause trouble off-course.
Isn’t this a fairly standard AJAX use-case for long-polling, etc.? (Caveat: I have not done web development like this in many many years.)
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.
Sounds useful. I’ve never used it, but it seems like it would fit the bill for notifications and such.
Suppose I have developed two games, let’s say App-1 and App-2 both of these games have lobby features. The functionality of lobby service is the same for all.
I can see two approaches to handle this on master server:
1- Having one lobby service (one war file connected to one data base) that handles lobby for all apps. And endpoint is dynamic like this
2- Having two lobby services (2 war files with separate databases) each handles one app. And endpoints are hardcoded like this
Which approach do you recommend?
From a developers point of view, the first would save me a lot of repeated code if all that was different was the name. The second would allow me to use separate code for separate logic.
There won’t be repeated code in the 2nd approach as well.
Just need to change these settings in the
application.properties once for each app before building the war file:
spring.data.mongodb.database= # once with app-1 DB and once with app-2 DB spring.data.mongodb.port= spring.data.mongodb.host= server.servlet.context-path= # once with /app-1 and once with /app-2
Then the first approach seems like it has less maintenance. Once you’ve written the code for invalid app names (just a 404 redirect) it’s all set up.
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.
@jayfella is this something to worry about?
Sorry if sounds stupid question
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.
Okay, I see. Thanks so much for the helps
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.
And I thought this is possible only through the 2nd approach with separate war files for each app, Yes?
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.
Yeah, will keep in mind. Thanks