Can you access the whole nakama api via the websocket connection or just the rtapi? We’re using the nakama-godot sdk, but upon inspection of the traffic, each rpc goes through an entire tcp+tls handshake + tear down on each request when there is an idle and active websocket connection for async nakama event callbacks. I may be missing something, or maybe it’s just the nakama-godot client sdk, but can we not access the entire nakama api via that open and available websocket conn?
No the API is separated into REST (for non-realtime data flow) and WS (for realtime data flow). This is done to ensure general server design philosophies are followed, which means most compatibility with game engines. A lot of games that don’t have a realtime component don’t need to have a WS connection to exchange data with the game server.
The flow of tcp+tls is also what every webserver in the world uses, and I doubt it is a performance bottleneck.
@jordo Interestingly we did have the whole API available on the socket in the very first major version of Nakama server. It proved not to be practical because the movement of core game data (game saves, etc) meant that the socket message buffers had to be really large for many kinds of games which opened the server up to slow client denial of service attacks.
The benefit of the SSL handshake elimination was not worth the attack vectors that could be opened against the server. Also with the HTTP keep-alive it mostly mitigates any overhead introduced by SSL handshakes. I suspect that there may be a good code contribution that can be added to the Godot client to enable keep-alive. It would be great if you could open a pull request contribution to the codebase. Thanks 
Yes, adding the keep-alive header and reusing the same connection on the HTTP/REST path was my first thought… But I was still curious why the API wasn’t available on the websocket as well. I’m coming from gamesparks, where the entire request API was available as HTTP/REST and websocket which was quite convenient.
The tcp open + TLS handshake for each api request does add a significant delay for our client right now, especially compared to anything like the PING/PONG that’s on the websocket conn. Will consider keep-alive on that path as the potential solution right now. Thanks