If using compression the size is in the same ballpark (protobuf can be between 20% and 50% smaller). For 99% of users it should not make a difference. https://nilsmagnus.github.io/post/proto-json-sizes/#gzipped-...
You also have solutions like GraphQL that define a schema, or you can publish some kind of schema (a good thing to do) but use JSON instead of a binary format.
- https://github.com/project-flogo/grpc/blob/master/proto/grpc...
- https://github.com/OAI/OpenAPI-Specification/blob/main/examp...
Both your application and documentation will assume certain state to be true, but only with type checking you can actually verify if it's correct.
(I still like protobuf, but the schemas are a terrible reason to like it.)
The principle benefit is that you can use the schema to define the data format, which means you can pack the data in more tightly (you don't need a byte to say "this is an object" if you know that the input data must be an object at this point). That's a big benefit in certain situations, but if you're using this sort of stuff just to get validation then you're probably better off using JSON Schema and having a wire transfer format that you can read easily without additional tools.
The link you included shows that protobufs are at least 15% better for all users, and as much as 57% better for cases where the data is small. Doesn't that mean for 100% of users it will actually make a difference?
Your users might not care about the difference but it will be there.
Actually realizing that speed up for your users will take time away from delivering features.
Engineering is a trade off, always will be.
You don't optimize things for the cases when they are fast. (Unless the gain is a couple of orders of magnitude; certainly not for a 50% speedup.)
The 15% gain is the one that matters. On practice, it comes at the expense of a more complex (thus larger, negating some of it) and less reliable system. It is very rare that this trade-off is worth it.
And if you are faced with a server that only speaks protobuf, the same question applies to the original devs: why did they make that decision?
If you are designing your own solution that uses protobuf instead of JSON say goodbye to a range of useful tools that the whole industry uses. From testing to automation it will be harder at every step, and you will have to find custom solutions instead of usual no-customization solution that works OOTB with JSON.
It is a good way to frustrate your developers and generate sometimes brittle solutions related to testing/automation/infrastructure.
My suggestion/strawman is to add request/response debug headers that include this in a standardized way. Then tooling can start to pick this up (eventually). The developer experience can then start to approach json.
Isn't it slower than protobufjs?
Otherwise personally json wins