3 ms·

I also disagree, at Google everything is RPCs in a similar way to gRPC internally, and I barely need to think about the mechanics of them most of the time, wher

I also disagree, at Google everything is RPCs in a similar way to gRPC internally, and I barely need to think about the mechanics of them most of the time, whereas with REST/raw HTTP, you need to think about so much of the process – connection lifecycle, keepalive, error handling at more layers, connection pools, etc. However, I used to work in a company that used HTTP internally, and moving to gRPC would have sucked. If you're the one adding gRPC to a new service, that's more of a pain than `import requests; requests.get(...)`. There is no quick and hacky solution for gRPC, you need a fully baked, well integrated solution, rolled out across everyone who will need it.

pianoben 2y ago
The flexibility of HTTP has advantages, too; it's simple to whip up a `curl` command to try things out. How does Google meet that need for gRPC APIs?
- allset_ 2y ago
  Server reflection exists (https://grpc.io/docs/guides/reflection/ https://grpc.io/docs/guides/reflection/), but you don't really need to whip out curl when you have the RPC service's definition. It tells you everything you need to know about what to send and what you will receive, so you can just start writing type-safe code.
  - bootsmann 2y ago
    >you don't really need to whip out curl when you have the RPC service's definition Following up a "how do I experiment with this in my workflow" with "oh you don't need to" is not the greatest look. There is a vast portion of programming bugs that stem from someone misunderstanding what a given API does, so the ability to quickly self-verify that one is doing things right is essential.
    - allset_ 2y ago
      As the linked docs mention, grpcurl is a thing if you want to use it.
- danpalmer 2y ago
  There's a curl for RPCs internally. It helps too that RPC servers are self describing, so you can actually list the services and methods exposed by a server. I'd say it's much simpler than curl, although again that's in large part because there's a lot of shared infra and understanding, and starting from scratch on that would be hard.

pianoben 2y ago

The flexibility of HTTP has advantages, too; it's simple to whip up a `curl` command to try things out. How does Google meet that need for gRPC APIs?

allset_ 2y ago
Server reflection exists (https://grpc.io/docs/guides/reflection/ https://grpc.io/docs/guides/reflection/), but you don't really need to whip out curl when you have the RPC service's definition. It tells you everything you need to know about what to send and what you will receive, so you can just start writing type-safe code.
- bootsmann 2y ago
  >you don't really need to whip out curl when you have the RPC service's definition Following up a "how do I experiment with this in my workflow" with "oh you don't need to" is not the greatest look. There is a vast portion of programming bugs that stem from someone misunderstanding what a given API does, so the ability to quickly self-verify that one is doing things right is essential.
  - allset_ 2y ago
    As the linked docs mention, grpcurl is a thing if you want to use it.
danpalmer 2y ago
There's a curl for RPCs internally. It helps too that RPC servers are self describing, so you can actually list the services and methods exposed by a server. I'd say it's much simpler than curl, although again that's in large part because there's a lot of shared infra and understanding, and starting from scratch on that would be hard.