Support application/grpc+json

[JamesNK]

Today we support application/grpc+proto and application/grpc (which infers proto).

Post V1, support JSON. Consider supporting custom message formats, e.g. application/grpc+ini

[davidfowl]

What is application/grpc+json? I read this https://grpc.io/blog/grpc-with-json but I don't understand the point of this thing. What does it mean for the codegen? What parts of the stack stay the same and what part ends up being different?

[JamesNK]

At a low level really the only difference is the marshallers. They hang off Method<,>, and I believe there is a 1 to 1 relationship between them.

Either we would extend Method<,> to support different marshallers depending on the message type, method.GetRequestMarshaller("proto").Deserializer, or we'd have different Method<,> instances for different message types.

Tooling is the difficult side. Grpc.Tools doesn't support JSON, but people could create types with their own binder methods that have method instances that supported JSON. With JSON code gen isn't as important because serialization is a lot more forgiving. The marshaller for JSON could be (message) => Encoding.UTF8.GetBytes(JsonConvert.SerializeObject(message))

[plaisted]

Tooling may not be a difficulty. Protobufs have a defined JSON mapping (spec) and the official c# protobuf library includes support for JSON marshalling using the above specification (docs). A single grpc-dotnet server should be able to serve both JSON and protobufs using the same Grpc.Tools codegen'd classes. I implemented protobufs or JSON support over HTTP (using aspcore) a while back and the protobuf tooling worked great for it.

[JohnGalt1717]

will this enable using json with grpc and getting rid of the highly problematic protobufs? (i.e. bad nullability support)