I’m developing a cli in Go for interacting with a nakama game.
I have the non-realtime component working using apigrpc.NakamaClient. The game also uses streams, and it’s not clear how to implement these client-side in Go.
I’d like to implement the Socket functionality found in the javascript client socket.ts in Go.
In particular, I need to implement MatchData and StreamData handlers (and possibly others later). I would also prefer using gRPC as the network transport, but websockets are fine if gRPC is not possible.
This issue golang client availability #346 alludes to using github.com/nakama-common/rtapi for real-time functionality, but I can’t find any examples of how to actually use it.
Can I get some help implementing an simple client that can send/receiveMatchData and StreamData? Thanks.
In particular, I need to implement MatchData and StreamData handlers (and possibly others later). I would also prefer using gRPC as the network transport, but websockets are fine if gRPC is not possible.
It’s not possible to use the gRPC protocol with the realtime socket features in Nakama because gRPC is not fast enough (at the network level) to implement multiplayer or our streams gameplay APIs. Instead we designed our socket layer to support different network transports.
Can I get some help implementing an simple client that can send / receiveMatchData and StreamData ? Thanks.
Sure. We don’t have any documentation on how to implement the socket portion of the Nakama API (except for the client sdks which are all open-source) but I can guide you through how it works:
The /ws?token="session token" endpoint in the server expects a WebSocket protocol upgrade message which will convert the HTTP request into an open socket connection.
The socket expects every message to have an envelope which is this protobuf message.
The socket can accept messages in binary or text mode but you cannot switch between one and the other.
The envelope message contains the marker for the content of the inner message to be consumed. This allows chat, multiplayer, status events, and other realtime messages to be multiplexed over a single socket.
Hope this helps. We’d like to have an official Go client implementation maintained in the source tree for the codebase at some point. All contributions are welcome.
Hi @novabyte , I hope you will reply to an old topic, but I didn’t want to create a new one.
I am pretty lost when it’s about realtime and go. So did I understand you correctly that we need to connect to a http websocket from a microservice to enable realtime features through that microservice?
Is there a way to generate those calls based on the realtime.proto? Or is this manual work?
I am trying to create a match through our golang microservice. The problem is, that it’s not covered in the NakamaClient interface in apigrpc. There is a proto definition for the realtime api in nakama commons but I cannot find any service or rcp endpoints for it
How would I create a match from a golang microservice then?
@matthiasbruns No worries. The thread bump is a good reminder that we’ve not provided the Go client SDK which I think will be of great value at this point to game teams that want to communicate with the Nakama APIs server to server.
Is there a way to generate those calls based on the realtime.proto? Or is this manual work?
There’s no way to code generate the socket object/type with its signatures and inputs/outputs in the same way as we’ve done with our GRPC API. It has to be hand written unfortunately. There’s an open issue to create a formal SDK for Go developers which you could bump the priority on.
How would I create a match from a golang microservice then?
You could create the match via a socket (or non-socket) RPC call but I’m curious at your use case. You want the match to be stared via another Go service but would game clients still connect direct to the Nakama servers to join and participate in the match?
@novabyte The use-case is a bit tricky. We would like to build something like skillz with Nakama as our backend but additional logic in microservices. For example quota for non-released games. We also want to have a central account system and use nakama custom auth to create player accounts per game (something like steam, where you also have one central account). This also includes virtual goods and real money. So we need some kind of middleware to handle the communication from the clients to a specific nakama instance based on the game they play. This is all in evauluation and maybe we will ditch the realtime proxy services completely, but I need to check first, if it is doable. As afar as I can see, Nakama uses the client ip for realtime communication, which would not work in our case then.
@matthiasbruns I think a customization or fork of Nakama would be a mistake because you’d have to maintain synchronization with the mainline codebase that we maintain. All that’s missed right now is a socket implementation as part of an official Go SDK. You could always sponsor or contribute the work to the codebase.
