search

golang / protobuf

Go support for Google's protocol buffers
BSD 3-Clause "New" or "Revised" License
9.66k stars 1.58k forks source link

Why is there no client service generated? #1513

Open JamesArthurHolland opened 1 year ago

JamesArthurHolland commented 1 year ago

Hard coding the usage of "client" everywhere is really poor because if ever the transport switches to graphql or something then because it's so tightly coupled to the grpc client it would be a nightmare to refactor.

Why is there no auto generated service class which wraps the clientInterface?

Having to write this manually is quite frustrating.

puellanivis commented 1 year ago

Your post is confusing me. github.com/golang/protobuf itself is deprecated for google.golang.org/protobuf/proto. While the former implemented gRPC generation, the latter no longer does. That is now handled by google.golang.org/grpc/cmd/protoc-gen-go-grpc. But even with the former, simply not specifying any services within the proto would prevent generation of any client or server code, and thus ends up just like the latter: protobuf implementation only.

Conceptually gRPC and GraphQL have very structurally different semantics. Yes, one can convert any form of RPC into another, but GraphQL is a Query Language, while gRPC is a Remote Procedure Call. I’m not sure one could just swap out the “transport” between the two of these without restructuring the codebase and redefining the contract in the first place.

Golang does not have a concept of “class”. Since receiver methods may receive any concrete type, we do not have to wrap everything through a common “class” semantic.

So, I’m having trouble understanding what exactly your complaint is here. Especially, without any concrete examples of what you’re referring to.

techbech commented 1 year ago

I think the complaint concerns what is also written in the documentation.

The Go code generator does not produce output for services by default. If you enable the gRPC plugin (see the gRPC Go Quickstart guide) then code will be generated to support gRPC.

This is at least a concern for me. I don't understand why there is no option for generating generic services as you get with CPP, TypeScript, etc.

Just a quick note. To enable it in CPP, you would use an option called cc_generic_services as described here.

puellanivis commented 1 year ago

I don’t think Golang needs that same sort of generic service generation? Since interfaces are duck-typed in Go, literally anything that implements the given functions is usable as the client interface without needing to have any sort of separate service class/type. The client interface bridges perfectly between the expectations already?

I suppose we could generate that client interface without needing to have the person use the gRPC plugin, since it’s pretty much gRPC agnostic… but I think there were concerns about where lines should be drawn to prevent this protobuf repo from needing to be changed in lock-step with any changes to the gRPC repo, which was the whole reason why we broke out the gRPC generation from the protobuf generation itself.

techbech commented 1 year ago

Correct me if I'm wrong, but I think we would also need to generate server interfaces.

I understand the concern about locking it with gRPC, but the service interfaces generated from Protobuf don't necessarily need to be used in gRPC. I suggest making the generated service interfaces optional, as that's also done for CPP, to prevent conflicts.