Add support for custom type/file "registries" to WithProtoJSON

[ppacher]

Is your feature request related to a problem? Please describe.

I'm working a lot with google/protobuf/any.proto and also created some kind of "descriptor-lookup" service pbtype-server. While retrieving FileDescriptor works pretty well I needed to copy&paste the protoJsonCodec to support a custom resolver.

Describe the solution you'd like

It would be awesome to extend the current WithProtoJSON to accept a custom type and message resolver.

Describe alternatives you've considered
Copy & paste the current protoJsonCodec implementation and add support to configure the type resolver.

Solution

Before:

path, handler := expamlev1connect.NewExampleClient(
    http.DefaultClient,
    url,
)

After:

path, handler := expamlev1connect.NewExampleClient(
    http.DefaultClient,
    url,
    connect.WithProtoJsonRegistry( myCustomerTypeResolver{} )
)

The interface should enforce implementation of either linker.Resolver or, if not required, protoreflect.MessageTypeResolver and protoreflect.ExtensionTypeResolver at least.

For example:

• https://github.com/tierklinik-dobersberg/events-service/blob/main/cmds/events-service/main.go#L108
• https://github.com/tierklinik-dobersberg/events-service/blob/main/internal/codec/json.go

I'd like to propose a PR but wanted to ask for feedback before!

[bufdev]

Thanks for the proposal. I don't think this is something we'd accept in the mainline repository - this seems like a perfect case to maintain your own Codec. We want to keep this library as lean as possible, and your extension for your advanced use case should live in your repository.

[jhump]

@ppacher, FWIW, there is a third-party library you could use to do this, created by one of the authors of connect-go: https://github.com/akshayjshah/connectproto
It allows you to create a codec where you can set the Resolver field in the protojson.MarshalOptions, protojson.UnmarshalOptions, and proto.UnmarshalOptions structs.

[ppacher]

@bufdev, @jhump , thanks for the response!

While I understand that you want to keep the lib as lean as possible I still think that the addition of a WithProtoJSONOptions( WithResolver(...)) wouldn't blow up the API surface to much and while still preserving backward comptability. Though, if this is out of scope for connect-go I'll accept it and try the mentioned solution from @jhump.