New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why is there no client service generated? #1513
Comments
Your post is confusing me. 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. |
I think the complaint concerns what is also written in the documentation.
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 |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: