What is Protobuf?
Who uses Protobuf?
Here are some stack decisions, common use cases and reviews by companies and developers who chose Protobuf in their tech stack.
gRPC with Protobuf has clear winning and pros and the most importantly easy and fun to write and scale
- HTTP/2 vs. HTTP 1.1
- Messages vs. Resources and Verbs
- 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
- 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.
- Bored of too much REST ?? ;)
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.