1

Scenario: I have two services/applications.

Application A is a game server, which receives events from game clients. This application now needs to request information from Application B for certain information, such as registered users etc. It also needs to send events to Application B. The language used is Java and there is nothing I can do about this.

Application B is an application that handles storage of users, contains authorization logic among other things. It also acts as an API for the whole thing, only Application B can communicate with Application A. This application needs to request information from Application A about certain things, such as configuration and connected users/game clients. It also needs to send events to Application A of events triggered via API interaction.

I realise that both applications could be written as one, but I would rather write the API and logic in NodeJS, since I'm more comfortable doing that and would rather not use Java. I've briefly looked at WebSockets, Sockets, and standard HTTP requests as means of communication but don't know what kind of communication that would suit this kind of communication/coupling.

rosengrenen
  • 731
  • 6
  • 21
  • Either webSockets or http requests would work just fine. If the communication is lots of small repeated requests and/or bi-directional, then webSockets make more sense. If only uni-directional (request/response), then http will work just fine. If you go plain TCP socket, then you have to basically build your own protocol sender and parser in order to package requests. That's not a huge deal, but both webSocket and http have already done it for you. If there are existing libraries that help with your specific task/content that already use http, that might be a reason to go with http. – jfriend00 May 04 '20 at 09:29
  • So it's all good to "send" an event using a http request? It just sounded strange but should work just fine, e.g. POST /disconnect to Application **B** would handle a player disconnecting – rosengrenen May 04 '20 at 09:44
  • Also, WebSocket's have a lower latency right? And I couldn't wrap my head around how to emulate request->response using them, any suggestion? – rosengrenen May 04 '20 at 09:46
  • 1
    webSocket should have lower latenct because the socket is already established, though more advanced versions of http get some of those advantages too. webSocket can definitely be lower overhead per request. – jfriend00 May 04 '20 at 09:50
  • 1
    webSocket is not as simple for request/response as http. You can emulate it by coining a transactionID in each request you send and echoing that back with the response. The receiving code then combines the response with the code that sent it. The transactionID can be something as simple as in an increasing counter. Each client would have their own because the IDs are specific to the client and the server just echoes it back with the response. You could use an eventEmitter and have the sender listen for their ID. Your websocket receiving code would then emit incoming data for an ID. – jfriend00 May 04 '20 at 09:52
  • sounds good! is there any limitation to using websockets compared to http requests, such as how many requests can be handled at once. this is uncharted territory to me so i have very little insight, but i imagine that each http requests open a need (tcp?) connection to the http server, while there is only one websocket (tcp?) connection in this case – rosengrenen May 04 '20 at 09:58
  • is there any need for an extra application that acts as the websocket server, or could one of the application just be the server? – rosengrenen May 04 '20 at 09:59
  • 1
    One of the applications can easily be the webSocket server. There are no traffic limits. I would think you could get better throughput (more requests/resposnes) on a single webSocket than using http connections because of all the extra overhead with http. – jfriend00 May 04 '20 at 10:01
  • cool, thanks for your input/help! – rosengrenen May 04 '20 at 10:16

0 Answers0