google.golang.org/grpc v1.29.1
go version)?go1.14.3 darwin/amd64
Following up on https://github.com/grpc/grpc-go/issues/2189, the server side was missed, it is still using the deprecated grpc.Codec interface.
// CustomCodec returns a ServerOption that sets a codec for message marshaling and unmarshaling.
//
// This will override any lookups by content-subtype for Codecs registered with RegisterCodec.
func CustomCodec(codec encoding.Codec) ServerOption {
return newFuncServerOption(func(o *serverOptions) {
o.codec = codec
})
}
// CustomCodec returns a ServerOption that sets a codec for message marshaling and unmarshaling.
//
// This will override any lookups by content-subtype for Codecs registered with RegisterCodec.
func CustomCodec(codec Codec) ServerOption {
return newFuncServerOption(func(o *serverOptions) {
o.codec = codec
})
}
// Codec defines the interface gRPC uses to encode and decode messages.
// Note that implementations of this interface must be thread safe;
// a Codec's methods can be called from concurrent goroutines.
//
// Deprecated: use encoding.Codec instead.
type Codec interface {
// Marshal returns the wire format of v.
Marshal(v interface{}) ([]byte, error)
// Unmarshal parses the wire format into v.
Unmarshal(data []byte, v interface{}) error
// String returns the name of the Codec implementation. This is unused by
// gRPC.
String() string
}
I believe CustomCodec should be marked deprecated, and there is no need to provide an alternative using encoding.Codec directly. Let me know if you have a use case for it.
Same use case as mentioned in the linked issue: https://github.com/grpc/grpc-go/issues/2189
I am trying to use https://github.com/mwitkow/grpc-proxy
func ExampleRegisterService() {
// A gRPC server with the proxying codec enabled.
server := grpc.NewServer(grpc.CustomCodec(proxy.Codec()))
// Register a TestService with 4 of its methods explicitly.
proxy.RegisterService(server, director,
"mwitkow.testproto.TestService",
"PingEmpty", "Ping", "PingError", "PingList")
}
I think we should keep this open to track adding a non-deprecated version of the API. The server-side use case seems just as appropriate as the client-side.
Same issue here - I want to use a custom codec for a particular gRPC server. I have more than one server in the program and ideally I'd prefer not to register a global codec. Also, I wonder what is the reasoning for adding global registries for codec and compressor? Allowing a per-server configuration is much more flexible and there is no thread-safety issues (global registries are not thread safe at the moment).
Sorry, more context: servers that I have should use different codecs for the same content type - global registry makes this hard to achieve. I can work this around, but it's not as clean as it could be with this issue resolved.
Most helpful comment
I think we should keep this open to track adding a non-deprecated version of the API. The server-side use case seems just as appropriate as the client-side.