3 ms·

> Why does gRPC have to use such a non-standard term for this that only mathematicians have an intuitive understanding of? I have to explain the term every time

> Why does gRPC have to use such a non-standard term for this that only mathematicians have an intuitive understanding of? I have to explain the term every time I use it. Who are you working with lol? Nobody I’ve worked with has struggled with this concept, and I’ve worked with a range of devs, including very junior and non-native-English speakers. > Also, it doesn’t pass my “send a friend a cURL example” test for any web API. Well yeah. It’s not really intended for that use-case? > The reliance on HTTP/2 initially limited gRPC’s reach, as not all platforms and browsers fully supported it Again, not the intended use-case. Where does this web-browsers-are-the-be-all-and-of-tech attitude come from? Not everything needs to be based around browser support. I do agree on http/3 support lacking though. > lack of a standardized JSON mapping Because JSON has an extremely anaemic set of types that either fail to encode the same semantics, or require all sorts of extra verbosity to encode. I have the opposite experience with protobuf: I know the schema, so I know what I expect to get valid data, I don’t need to rely on “look at the json to see if I got the field capitalisation right”. > It has made gRPC less accessible for developers accustomed to JSON-based APIs Because god forbid they ever had to learn anything new right? Nope, better for the rest of us to just constantly bend over backwards to support the darlings who “only know json” and apparently can’t learn anything else, ever. > Only google would think not solving dependency management is the solution to dependency management Extremely good point. Will definitely be looking at Buf the next time I touch GRPC things. GRPC is a lower-overhead, binary rpc for server-to-server or client-server use cases that want better performance and faster integration that a shared schema/IDL permits. Being able to drop in some proto files and automatically have a package with the methods available and not having to spend time wiring up url’s and writing types and parsing logic is amazing. Sorry it’s not a good fit for serving your webpage, criticising it for not being good at web stuff is like blaming a tank for not winning street races. GRPC isn’t without its issues and shortcomings- I’d like to see better enums and a stronger type system, and defs http/3 or raw quic transport.

lanstin 2y ago
I use protobuf to specify my protocol and then generate a swagger/openAPI spec then use some swagger codegen to generate rest client libraries. For a proxy server I have to fill in some stub methods to parse the json and turn it into a gRPC call but for the gRPC server there is some library that generates a rest service listener that just calls into the gRPC server code. It works fine. I had to annotate the proto file to say what REST path to use.
sudorandom 2y ago
Hey, author here: > Why does gRPC have to use such a non-standard term for this that only mathematicians have an intuitive understanding of? I have to explain the term every time I use it. >> Who are you working with lol? Nobody I’ve worked with has struggled with this concept, and I’ve worked with a range of devs, including very junior and non-native-English speakers. This is just a small complaint. It's super easy to explain what unary means but it's often infinitely easier to use a standard industry term and not explain anything. >> Also, it doesn’t pass my “send a friend a cURL example” test for any web API. > Well yeah. It’s not really intended for that use-case? Yeah, I agree. Being easy to use isn't the indented use-case for gRPC. >> The reliance on HTTP/2 initially limited gRPC’s reach, as not all platforms and browsers fully supported it > Again, not the intended use-case. Where does this web-browsers-are-the-be-all-and-of-tech attitude come from? Not everything needs to be based around browser support. I do agree on http/3 support lacking though. I did say browsers here but the "platform" I am thinking of right now is actually Unity, since I do work in the game industry. Unity doesn't have support for HTTP/2. It seems that I have different experiences than you, but I still think this point is valid. gRPC didn't need to be completely broken on HTTP/1.1. >> lack of a standardized JSON mapping > Because JSON has an extremely anaemic set of types that either fail to encode the same semantics, or require all sorts of extra verbosity to encode. I have the opposite experience with protobuf: I know the schema, so I know what I expect to get valid data, I don’t need to rely on “look at the json to see if I got the field capitalisation right”. I agree that it's much easier to stick to protobuf once you're completely bought-in but not every project is greenfield. Before a well-defined JSON mapping and tooling that adhered to it is is very hard to transition from JSON to protobuf. Now it's a lot easier. >> It has made gRPC less accessible for developers accustomed to JSON-based APIs > Because god forbid they ever had to learn anything new right? Nope, better for the rest of us to just constantly bend over backwards to support the darlings who “only know json” and apparently can’t learn anything else, ever. No comment. I think we just have different approaches to teaching. >> Only google would think not solving dependency management is the solution to dependency management > Extremely good point. Will definitely be looking at Buf the next time I touch GRPC things. I'm glad to hear it! I've had nothing but execellent experiences with buf tooling and their employees. > GRPC is a lower-overhead, binary rpc for server-to-server or client-server use cases that want better performance and faster integration that a shared schema/IDL permits. Being able to drop in some proto files and automatically have a package with the methods available and not having to spend time wiring up url’s and writing types and parsing logic is amazing. Sorry it’s not a good fit for serving your webpage, criticising it for not being good at web stuff is like blaming a tank for not winning street races. Without looping in the frontend (aka web) it makes the contract-based philosophy of gRPC much less compelling. Because without that, you would have to have a completely different language for contracts between service-to-service (protobuf) than frontend to service (maybe OpenAPI). For the record: I very much prefer protobufs for the "contract source of truth" to OpenAPI. gRPC-Web exists because people wanted to make this work but they built their street racer with some tank parts. > GRPC isn’t without its issues and shortcomings- I’d like to see better enums and a stronger type system, and defs http/3 or raw quic transport. Totally agree!
SrslyJosh 2y ago
>> Also, it doesn’t pass my “send a friend a cURL example” test for any web API. > Well yeah. It’s not really intended for that use-case? Until $WORKPLACE is invaded by Xooglers who want to gRPC all the things, regardless of whether or not there's any benefit over just using HTTPS. Internal service with dozens of users in a good week? Better use gRPC!
- FridgeSeal 2y ago
  Oh yeah, no technology can design against being improperly deployed. I certainly don’t advocate for GRPC-ing-all-the-things! Suitable services only!

lanstin 2y ago

I use protobuf to specify my protocol and then generate a swagger/openAPI spec then use some swagger codegen to generate rest client libraries. For a proxy server I have to fill in some stub methods to parse the json and turn it into a gRPC call but for the gRPC server there is some library that generates a rest service listener that just calls into the gRPC server code. It works fine. I had to annotate the proto file to say what REST path to use.

sudorandom 2y ago

Hey, author here: > Why does gRPC have to use such a non-standard term for this that only mathematicians have an intuitive understanding of? I have to explain the term every time I use it. >> Who are you working with lol? Nobody I’ve worked with has struggled with this concept, and I’ve worked with a range of devs, including very junior and non-native-English speakers. This is just a small complaint. It's super easy to explain what unary means but it's often infinitely easier to use a standard industry term and not explain anything. >> Also, it doesn’t pass my “send a friend a cURL example” test for any web API. > Well yeah. It’s not really intended for that use-case? Yeah, I agree. Being easy to use isn't the indented use-case for gRPC. >> The reliance on HTTP/2 initially limited gRPC’s reach, as not all platforms and browsers fully supported it > Again, not the intended use-case. Where does this web-browsers-are-the-be-all-and-of-tech attitude come from? Not everything needs to be based around browser support. I do agree on http/3 support lacking though. I did say browsers here but the "platform" I am thinking of right now is actually Unity, since I do work in the game industry. Unity doesn't have support for HTTP/2. It seems that I have different experiences than you, but I still think this point is valid. gRPC didn't need to be completely broken on HTTP/1.1. >> lack of a standardized JSON mapping > Because JSON has an extremely anaemic set of types that either fail to encode the same semantics, or require all sorts of extra verbosity to encode. I have the opposite experience with protobuf: I know the schema, so I know what I expect to get valid data, I don’t need to rely on “look at the json to see if I got the field capitalisation right”. I agree that it's much easier to stick to protobuf once you're completely bought-in but not every project is greenfield. Before a well-defined JSON mapping and tooling that adhered to it is is very hard to transition from JSON to protobuf. Now it's a lot easier. >> It has made gRPC less accessible for developers accustomed to JSON-based APIs > Because god forbid they ever had to learn anything new right? Nope, better for the rest of us to just constantly bend over backwards to support the darlings who “only know json” and apparently can’t learn anything else, ever. No comment. I think we just have different approaches to teaching. >> Only google would think not solving dependency management is the solution to dependency management > Extremely good point. Will definitely be looking at Buf the next time I touch GRPC things. I'm glad to hear it! I've had nothing but execellent experiences with buf tooling and their employees. > GRPC is a lower-overhead, binary rpc for server-to-server or client-server use cases that want better performance and faster integration that a shared schema/IDL permits. Being able to drop in some proto files and automatically have a package with the methods available and not having to spend time wiring up url’s and writing types and parsing logic is amazing. Sorry it’s not a good fit for serving your webpage, criticising it for not being good at web stuff is like blaming a tank for not winning street races. Without looping in the frontend (aka web) it makes the contract-based philosophy of gRPC much less compelling. Because without that, you would have to have a completely different language for contracts between service-to-service (protobuf) than frontend to service (maybe OpenAPI). For the record: I very much prefer protobufs for the "contract source of truth" to OpenAPI. gRPC-Web exists because people wanted to make this work but they built their street racer with some tank parts. > GRPC isn’t without its issues and shortcomings- I’d like to see better enums and a stronger type system, and defs http/3 or raw quic transport. Totally agree!

SrslyJosh 2y ago

>> Also, it doesn’t pass my “send a friend a cURL example” test for any web API. > Well yeah. It’s not really intended for that use-case? Until $WORKPLACE is invaded by Xooglers who want to gRPC all the things, regardless of whether or not there's any benefit over just using HTTPS. Internal service with dozens of users in a good week? Better use gRPC!

FridgeSeal 2y ago
Oh yeah, no technology can design against being improperly deployed. I certainly don’t advocate for GRPC-ing-all-the-things! Suitable services only!