3 ms·

We had a client choose protobufs / grpc which totally stalled the developers and created alot of problems and complexity. The client insisted for whatever reaso

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.

jimbokun 2y ago
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.
- lostemptations5 2y ago
  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.
  - metaltyphoon 2y ago
    > our developers had never used it before and found it counterintuitive and hard to find good information on how to use. This heavy says your developers might be the problem…
  - pjc50 2y ago
    > Bugs were hard to diagnose 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.
fullstop 2y ago
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.
- Spivak 2y ago
  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.
  - tonyarkles 2y ago
    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"
dagw 2y ago
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).
jki275 2y ago
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.
beeboobaa3 2y ago
Sure that happens if the people working on your project are incompetent, and then start blaming you.

jimbokun 2y ago

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.

lostemptations5 2y ago
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.
- metaltyphoon 2y ago
  > our developers had never used it before and found it counterintuitive and hard to find good information on how to use. This heavy says your developers might be the problem…
- pjc50 2y ago
  > Bugs were hard to diagnose 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.

fullstop 2y ago

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.

Spivak 2y ago
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.
- tonyarkles 2y ago
  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"

dagw 2y ago

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).

jki275 2y ago

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.

beeboobaa3 2y ago

Sure that happens if the people working on your project are incompetent, and then start blaming you.