Closed Decencies closed 7 months ago
I'm not familiar with protobuf, is it just a spec similar to OpenAPI or is it also a specific way of serializing the data? My primary goal when making the current implementation was to keep it as standard as netty and Minecraft's PacketByteBuf. The reason is that I felt it is what most developers would likely look at using from what the client provides.
Are there any major benefits to protobuf vs the current implementation also? I don't foresee something such as multiple languages being very beneficial for the goal of this project, which is mods for the Java Minecraft client
Using protobuf serves no benefit here.
The current implementation seems to be very efficient, what kind of "clutter" in serialization logic do you see here, especially for the api user?
multi-language support is unneccessary for Minecraft: Java Edition
With things like mineflayer and other Minecraft cross-language APIs, protobuf generation could be helpful.
It creates a higher entry barrier for devs
not really? protobuf is relatively simple, and it would be a similar api regardless
It adds a fullblown new library to every hypixel mod without need.
protobuf core is 1.7 MB as of now.
Since Hypixel's internal APIs don't already use protobuf, it doesn't make sense to start using it for this specific API. Also protobuf isn't meant for this
@pauliesnug The example of mineflayer is a bad one - this api as well as the whole hypixel server is not created to serve headless clients.
ProtoBuf is also easier to manage and understand, since it can be verified on server and client. Although if Hypixel's internal APIs don't already use protobuf, I understand that it probably doesn't make sense to start using it for this specific API.
Please do not use ProtoBuf. Use a sensible protocol encoding library like capnproto or something hand rolled.
On a more serious note: protobuf does not really provide many benefits over minecrafts native methods. Protobuf is also just generally a worse option for any project not on the scale of google. There is a lot of leniency that makes working with them very cumbersome and error prone to work with. There are ways to remedy this, but even protobufs own authors recommend other libraries over it and (as most projects made by google) protobuf intentionally trades in human capital for slight efficiency gains. I can whole heartedly recommend not using protobuf for most things, and especially in this context, where a more standard and easier alternative already presents itself.
I think based on the split opinions here and the current implementation being more for our intended target audience we'll be sticking with that, but thanks for the suggestion!
Please consider using protobuf as a measure to unify the message definitions between different components which may implement this API.
Protobuf is a simple serialization framework which generates fast serde methods based on definitions written in a file; these definitions are portable between 10+ different languages and generally offer a clearer understanding of the data within the messages as there is no clutter presented from the serialization logic.
For more information please refer to: https://protobuf.dev/getting-started/javatutorial