4 ms·

My only work experience with gRPC was on a project where another senior dev pushed for it because we "needed the performance". We ended up creating a JSON API a

My only work experience with gRPC was on a project where another senior dev pushed for it because we "needed the performance". We ended up creating a JSON API anyways. Mostly because that's what the frontend could consume. No one except for that developer had experience with gRPC. He didn't go any deeper than the gRPC Python Quick start guide and wouldn't help fix bugs. The project was a mess for a hundred reasons and never got any sort of scale to justify gRPC. That said, I've used gRPC in bits outside of work and I like it. It requires lot more work and thought. That's mostly because I've worked on so many more JSON APIs.

lordofgibbons 2y ago
That sounds more like a critique of the "senior" developer who didn't know grpc isn't compatible with browsers before adopting it than grpc itself.
- NAHWheatCracker 2y ago
  Correct, I wasn't critiquing gRPC. I was critiquing a type of person who might push for gRPC. That developer probably thought of it as a novelty and made up reasons to use it. It was a big hassle that added to that teams workload with no upside.
  - reactordev 2y ago
    When all you have is a hammer… gRPC is fantastic for its use case. Contract first services with built in auth. I can make a call to a service using an API that’s statically typed due to code generation and I don’t have to write it. That said, it’s not for browsers so Mr gRPC dev probably had no experience in browser technologies. A company I worked for about 10 years ago was heavy gRPC but only as a service bridge that would call the REST handler (if you came in over REST, it would just invoke this handler anyway). Everything was great and dtos (messages) were automatically generated! Downside was the serialization hit.
    - whoevercares 2y ago
      gRPC is indeed for backend service to service calls with strong contract/model first approach. It’s important for company in serious API and SDK vending business.
- awinter-py 2y ago
  yes who would imagine that the homegrown rpc of the internet and browser company would work on the internet and in a browser very fair critique

lordofgibbons 2y ago

That sounds more like a critique of the "senior" developer who didn't know grpc isn't compatible with browsers before adopting it than grpc itself.

NAHWheatCracker 2y ago
Correct, I wasn't critiquing gRPC. I was critiquing a type of person who might push for gRPC. That developer probably thought of it as a novelty and made up reasons to use it. It was a big hassle that added to that teams workload with no upside.
- reactordev 2y ago
  When all you have is a hammer… gRPC is fantastic for its use case. Contract first services with built in auth. I can make a call to a service using an API that’s statically typed due to code generation and I don’t have to write it. That said, it’s not for browsers so Mr gRPC dev probably had no experience in browser technologies. A company I worked for about 10 years ago was heavy gRPC but only as a service bridge that would call the REST handler (if you came in over REST, it would just invoke this handler anyway). Everything was great and dtos (messages) were automatically generated! Downside was the serialization hit.
  - whoevercares 2y ago
    gRPC is indeed for backend service to service calls with strong contract/model first approach. It’s important for company in serious API and SDK vending business.
awinter-py 2y ago
yes who would imagine that the homegrown rpc of the internet and browser company would work on the internet and in a browser very fair critique