I was wondering if it was possible to use gRPC codegen and Nakama Runtime modules together. Specifically, I’d like to define my own service proto file (just like nakama/apigrpc.proto at master · heroiclabs/nakama · GitHub) and codegen server API and client API stubs, and somehow use those with Nakama Runtime if possible.
If this is not possible, I assume we would have to migrate off Nakama Runtime modules and fork Nakama instead.
Hey @pahdo, yes this is absolutely a recommended pattern. You can generate the stubs for use on your client and your Go runtime modules. You can use either gRPC or JSON via the Protobuf JSON parser to communicate between the server and client. In general, we don’t recommended forking Nakama because otherwise it won’t work with Heroic Cloud/our enterprise clustering technology.
So I wrote a basic service in proto with 1 API. I generated Go server stubs. How exactly would I integrate this using runtime modules?
The most straightforward solution to me would be
Instantiating a server object of my own from the generated server struct at this line. I’m assuming that’s not the suggestion b/c that would require forking Nakama.
Another option would be to implement these generated functions:
func (UnimplementedCustomFooServer) GetBar(context.Context, *GetBarRequest) (*GetBarResponse, error)
…
and then in the registered Nakama runtime rpc handler, instantiating a CustomFooServer with some of a reference to nk runtime, the db pointer, etc., and calling the GetBar function within that. It seems a bit roundabout and a strange pattern, does this seem right?
Re-reading your original message with the context of your last message, it looks like what you are after is type-safety and also being able to have the same protocol on the client/server. Additionally, you aren’t looking to use gRPC within Nakama to make server-to-server calls (you’d like to make the client-server gRPC on the back of a Nakama RPC).
I think the easiest and most straight-forward way to achieve the above is just to use Protobuf (but not gRPC). This way your message format is Protobuf binaries, you can generate them as you mentioned, and also send JSON-marshalled protobuf messages as request payload for a RPC or response of a RPC.