Protobuf

Protobuf

Application and Data / Languages & Frameworks / Serialization Frameworks
CEO at Scrayos UG (haftungsbeschränkt)·

We've already been monitoring Agones for a few years now, but we only adapted Kubernetes in mid 2021, so we could never use it until then. Transitioning to Kubernetes has overall been a blast. There's definitely a steep learning curve associated with it, but for us, it was certainly worth it. And Agones plays definitely a part in it.

We previously scheduled our game servers with Docker Compose and Docker Swarm, but that always felt a little brittle and like a really "manual" process, even though everything was already dockerized. For matchmaking, we didn't have any solution yet.

After we did tons of local testing, we deployed our first production-ready Kubernetes cluster with #kubespray and deployed Agones (with Helm) on it. The installation was very easy and the official chart had just the right amount of knobs for us!

The aspect, that we were the most stunned about, is how seamless Agones integrates into the Kubernetes infrastructure. It reuses existing mechanisms like the Health Pings and extends them with more resource states and other properties that are unique to game servers. But you're still free to use it however you like: One GameServer per Game-Session, one GameServer for multiple Game-Sessions (in parallel or reusing existing servers), custom allocation mechanisms, webhook-based scaling, ... we didn't run into any dead ends yet.

One thing, that I was a little worried about in the beginning, was the SDK integration, as there was no official one for Minecraft/Java. And the two available inofficial ones didn't satisfy our requirements for the SDK. Therefore, we went and developed our own SDK and ... it was super easy! Agones does publish their Protobuf files and so we could generate the stubs with #Protoc. The existing documentation regarding Client-SDKs from Agones was a great help in writing our own documentation for the interface methods.

And they even have excellent tooling for testing your own SDK implementations. With the use of Testcontainers we could just spin up the local SDK testing image for each of the integration tests and could confirm that our SDK is working fine. We discovered a very small inconsistency for one of the interface methods, submitted an issue and a corresponding PR and it was merged within less than 24 hours.

We've now been using Agones for a few months and it has proven to be very reliable, easy to manage and just a great tool in general.

READ MORE
12 upvotes·345.2K views
Fullstack Engineer| Ruby | React JS | gRPC at Ex Bookmyshow | Furlenco | Shopmatic·

gRPC with Protobuf has clear winning and pros and the most importantly easy and fun to write and scale

  1. HTTP/2 vs. HTTP 1.1
  2. Messages vs. Resources and Verbs
  3. The gRPC Gateway. Server 2 Server (S2S) calls in mind- gRPC is way to go. Browser support is not as mature. gRPC is mainly used primarily for internal services that are not exposed directly to the world. Exposing that big workflow for your order, warehouse, async jobs management as API service and RPC call scripted using gRPC is way to go
  4. Streaming vs. Request-Response. Try built-in health check streaming service and understand the use case. Ever wanted S2S streaming w/o browser involved, this is the solution.
  5. Bored of too much REST ?? ;)
READ MORE
gRPC – gRPC Basics - Ruby (grpc.io)
8 upvotes·1 comment·305.9K views
Anmol Deep
Anmol Deep
·
May 4th 2020 at 6:29AM

Weird to see videos on youtube (to promote grpc) talking about REST API is hard to write and the solution being gRPC . Even for an S2S communication REST API client server communication is good . Why gRPC ??

·
Reply