We had a client choose protobufs / grpc which totally stalled the developers and created alot of problems and complexity. The client insisted for whatever reason and eventually ran out of money. Their unfinished code is sitting in some Github repository somewhere.
Run very fast from it, unless you have a VERY good reason to use it.
Could you explain more. I'm using protobuf (without grpc) in a project right now. Yes, getting your toolchain set up to compile and update everything when you make edits to your .proto files takes a little bit of work and you need to do some planning ahead when it comes to your data model since you're not quite as flexible as JSON, but on the whole it has been not much trouble at all.
And on the performance side, parsing our data takes ~1 second in JSON vs ~0.03 seconds with protobuf (in python).
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.
Protobuf is rarely the issue, it's always grpc. If you see someone complaining about protobuf it's almost always because they used grpc. You can see it in this thread plain to see. Anyone who used it on its own is happy with it.
Yeah, I've used protobufs in production for at least a decade but haven't ever used gRPC in anger. It's come up a few times over the years and each time I look at it I just shudder and think "nope, that's not a level of complexity this project needs"
Comments
We had a client choose protobufs / grpc which totally stalled the developers and created alot of problems and complexity. The client insisted for whatever reason and eventually ran out of money. Their unfinished code is sitting in some Github repository somewhere.
Run very fast from it, unless you have a VERY good reason to use it.
Could you explain more. I'm using protobuf (without grpc) in a project right now. Yes, getting your toolchain set up to compile and update everything when you make edits to your .proto files takes a little bit of work and you need to do some planning ahead when it comes to your data model since you're not quite as flexible as JSON, but on the whole it has been not much trouble at all.
And on the performance side, parsing our data takes ~1 second in JSON vs ~0.03 seconds with protobuf (in python).
Sure that happens if the people working on your project are incompetent, and then start blaming you.
I've never used grpc, but my experience with protobuf is that it's quite easy to write and integrate. easier than xml or json at least.
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…
I've used it for marshalling data and it's worked quite well for us. I did not use grpc, though.
Perhaps my use case was far more simple.
Protobuf is rarely the issue, it's always grpc. If you see someone complaining about protobuf it's almost always because they used grpc. You can see it in this thread plain to see. Anyone who used it on its own is happy with it.
Yeah, I've used protobufs in production for at least a decade but haven't ever used gRPC in anger. It's come up a few times over the years and each time I look at it I just shudder and think "nope, that's not a level of complexity this project needs"