Interfacing with Nakama through a separate gateway server - please review our approach!

Game Design
1

Hello! We’re a small team that have just started building our first multiplayer game, and would like some guidance on our approach.

Currently, we have clients connecting directly to a Nakama instance - in our Kubernetes cluster - for authentication, storage & matchmaking. When a match is found, Nakama allocates a game server on our Agones fleet (FleetManager implementation PR soon, TM!).

We’re now looking to spike an implementation for metagame functionality (e.g. daily achievements, spending gold). We know we can achieve all of this with custom runtime modules; however, our devs are heavily C#-based, and our Go code is getting more and more hack-y.

We’d instead like to host our own gateway server responsible for interfacing with Nakama, which will expose it’s own endpoints for the client. Our idea is:

  1. Clients send an auth request, which is passed through to Nakama.
  2. When successful, the JWT is passed back to the client.
  3. When the gateway server receives any subsequent requests, it will restore the Nakama session from the provided JWT in the request in order to call the associated function in Nakama on behalf of the client.

We’re thinking this will essentially allow the gateway server to replace any functionality we might have otherwise used the custom runtime for.

Is this an accepted way to use Nakama, or are we overcomplicating things and should just use the runtime? Are there any gotcha’s we should be prepared for with this approach?

Thank you kindly for your time.

2

Hello @chrisanicolaou,

There’s no inherent problem in taking this approach, other than the increased operational complexity of having an additional “bridge” server and all that it entails.

I can’t speak on behalf of your team, but I’d argue that unless there’s complex authoritative match handler logic involved (and I suppose there shouldn’t be, since you’ll be running Agones headless instances), then the benefits of this approach may be limited.

My advice to someone coming from an Object Oriented language would be to avoid trying to replicate the same patterns in Go. Just write the code you need to make things work, and try to not overthink modularization, abstractions and other typical OOP patterns.

We’d like to eventually abstract the Nakama runtime to be somewhat language agnostic by introducing a WebAssembly runtime, but this is still just an idea, no real effort into laying it out has been made thus far.

The other drawback of the mentioned approach, is that it may limit your ability to move over to Heroic Cloud in the future, if that matters to you.

Regards.

3

Hi - thank you for the well-thought out reply.

That makes a lot of sense. We’ve agreed that, given we’re building from the ground up, it doesn’t seem sensible to waste so much resource on a gateway server just to keep things in C#. We’d likely waste more time on maintenance than we would have just learning Go from the get go (pun intended).

Thanks again for your input!

Kind regards