What was the source of the complexity? I haven't used protobuf for any production code, but the concept seems pretty straight forward.
I do see how it could be premature optimization, as JSON is even quicker to get up and running, and the overhead of bigger payloads and parsing costs isn't relevant until you've achieved some scale.
Its a great question-- our developers had never used it before and found it counterintuitive and hard to find good information on how to use. Projects are under time pressure so it's hard sometimes to have the mental space to properly grok a new framework, especially if its quite different.
I'm sure it works well for Google.
Also the support tools are lacking generally compared to say JSON or SQL or Python or any other technology.
Bugs were hard to diagnose-- I'm assuming if you were a grpc pro this would be ok.
Comments
What was the source of the complexity? I haven't used protobuf for any production code, but the concept seems pretty straight forward.
I do see how it could be premature optimization, as JSON is even quicker to get up and running, and the overhead of bigger payloads and parsing costs isn't relevant until you've achieved some scale.
Its a great question-- our developers had never used it before and found it counterintuitive and hard to find good information on how to use. Projects are under time pressure so it's hard sometimes to have the mental space to properly grok a new framework, especially if its quite different.
I'm sure it works well for Google.
Also the support tools are lacking generally compared to say JSON or SQL or Python or any other technology.
Bugs were hard to diagnose-- I'm assuming if you were a grpc pro this would be ok.
What sort of bugs - bugs in code using GRPC, or in the GRPC client/server code itself?
At least in the languages I've used with it you can dump GPRC messages to json if you need to get aggressive with logging detail to find something.
This heavy says your developers might be the problem…