But from my experience you use the code generator and trust the deserializer and serializer since they are unit tested. So you can just unit test your methods and don’t have to look at the actual binary blob payload.

You trust that gRPC is battle tested and you can just test your code.

You would probably wrap the generated methods/objects/structs in your own domain model and unit test the mapping between them. Using the objects from gRPC throughout your code directly does work but sometimes is not what you want to work with.

So I rather would introduce another boundary to the transport. But that is personal preference (in case I want to get rid of gRPC and don’t want to touch my business logic)

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.

For in-browser use with gRPCweb, if you use test-proto-on-XHR, things continue to work as with REST/JSON.

For inter-server debugging, you usually defer to opentracing or similar, and capture request data there.