What does HackerNews think of grpcurl?

> What is the ubiquitous utility for interacting with gRPC? We have curl for REST. What is openAPI of gRPC?

grpcurl[1] combined with gRPC server reflection[2]. The schema is compiled into the server as an encoded proto which is exposed via server reflection, which grpcurl reads to send correctly encoded requests.

[1] https://github.com/fullstorydev/grpcurl [2] https://github.com/grpc/grpc/blob/master/doc/server-reflecti...

There is also a very nice Grpc curl that is like curl but protobuf and reflection aware. I think this is it. https://github.com/fullstorydev/grpcurl

If you mean actual testing, we use a lot of mocks and this[1] little dude.

[1] https://github.com/fullstorydev/grpcurl

GrpCurl helps a bit with this.

https://github.com/fullstorydev/grpcurl

> unless you have Google's size microservices and infrastructure gRPC (with protocol buffers) is just tedious

Having used gRPC in very small teams (<5 engineers touching backend stuff) I had a very different experience from yours.

> need an extra step when doing protoc compilation of your models

For us this was hidden by our build systems. In one company we used Gradle and then later Bazel. In both you can set it up so you plop a .proto into a folder and everything "works" with autocompletes and all.

> cannot easily inspect and debug your messages across your infrastructure without a proper protobuf decoder/encoder

There's a lot of tooling that has recently been developed that makes all of this much easier.

- https://github.com/fullstorydev/grpcurl

- https://github.com/uw-labs/bloomrpc

- https://kreya.app/

You can also use grpc-web as a reverse proxy to expose normal REST-like endpoints for debugging as well.

> If you talk with other non-Go services then a JSON or XML transport encoding will do the job too (JSON rpc).

The benefit of protos is they're a source of truth across multiple languages/projects with well known ways to maintain backwards comparability.

You can even build tooling to automate very complex things:

- Breaking Change Detector: https://docs.buf.build/breaking-usage/

- Linting (Style Checking): https://docs.buf.build/lint-usage/

There's many more things that can be done but you get the idea.

On top of this you get something else that is way better: Relatively fast server that's configured & interfaces with the same way in every programming language. This has been a massive time sink in the past where you have to investigate nginx/*cgi, sonic/flask/waitress/wsgi, rails, and hundreds of other things for every single language stack each with their own gotchas. gRPC's ecosystem doesn't really have that pain point.

There is tooling built to easily do grpc requests from the command line[0] or even a GUI if that's your thing[1].

The tooling isn't quite as ubiquitous as cURL, but if anything I would think that its even easier because you have introspection into the contract with a .proto file.

[0] https://github.com/fullstorydev/grpcurl [1] https://github.com/uw-labs/bloomrpc

In general, not nearly as mature. In general though, gRPC is not for browser->server calls (grpc-web notwithstanding) but is designed for server<->server communication.

There is some tooling out there for development (https://github.com/fullstorydev/grpcurl and https://github.com/fullstorydev/grpcui are pretty nice) but it's still much less mature than the massive amount of mature tooling available for HTTP-based services. And that is both an artifact of gRPCs relative youth compared to REST and also for some more fundamental reasons (binary wire format, mutual TLS based authentication, etc).

All that said, I've been working with gRPC over the past 6 months or so and overall the development experience is much nicer on net I think.

> But you can't curl the state of your infra component without creating a program and downloading the client artifacts.

You can if you enable server reflection[1] and use a tool like grpcurl[2].

[1]: https://github.com/grpc/grpc-java/blob/master/documentation/... [2]: https://github.com/fullstorydev/grpcurl

> If I want to perform some rough tests of an endpoint during development, all I need to do is compose the json request and fire it off using curl. The response then comes back in a human readable format I can parse straight from the terminal. Boom, simple test conducted in less than 1 minute. I don't even need to think about it.

https://github.com/fullstorydev/grpcurl