feat(build): Better support for custom codecs

[bmwill]

@LucioFranco after we chatted briefly on discord yesterday I did a bit more thinking about how improve accessibility of the code generation functionality in tonic-build. This is one potential approach. Its in a WIP state but I wanted to get your thoughts and see if this is something you'd be interested in as a contribution to tonic. If so I can spend some time actually making it usable.

Motivation

gRPC is a general purpose RPC framework that, while generally is paired with protobuf, is agnostic to the type of serialization format used for messages and in some cases it may be desired to use a different serialization format other than protobuf.

Solution

This PR takes a look at one possible way to enable using a custom, non-protobuf codec for serializing messages to the wire. This is done via:

• changing the CODEC_PATH constant to a method which returns a &str for better programability
• introduces a set of builders for Services and Methods so that you can build up a service with various methods and invoke the code generation without interacting with prost or proto files. This could eventually enable developing a proc-macro that does the generation at compile time instead of needing a build script (for services which don't leverage proto files and protobuf)

[LucioFranco]

I like this a lot! I think just need to add some docs and we can merge this. Thanks!

[LucioFranco]

cfg test?

[bmwill]

Yeah i just whipped this together to see what you thought so now that I know you're interested i'll clean it up with docs and the like

[bmwill]

Ok this should be ready for a serious review now. My main question is how you want to handle the module naming, right now its all just in a public module rust and nothing is reexported at the top level.

[LucioFranco]

@bmwill how about manual instead of rust for the module name?

[bmwill]

@LucioFranco yeah manual is a bit more descriptive. I've updated the PR to reflect that change.

[LucioFranco]

Overall looks great left a few comments/questions.

[LucioFranco]

Do we actually need this extra struct? I don't mind keeping it just seems like we could just embed the code in the compile method?

[bmwill]

I was sort of following the pattern as exists in the prost.rs file. The extra struct sort of helps with the bookkeeping so it's probably worth keeping just for keeping the compile method simple.

[bmwill]

@LucioFranco Ok I've updated the PR, hopefully addressing all of your comments

[LucioFranco]

Thanks! LGTM

[zbysir]

@bmwill Take a look at this: #851, can you give me some advice? First of all thank you.

What I want most is to support multiple codecs, not a specific one.

[bmwill]

@zbysir Ah interesting! Yeah one thing this change does not handle is looking at/changing the content-type header. I did ask @LucioFranco about it and he seemed to indicate that there were some implementations out that that couldn't handle a value of application/grpc+{encoding} so the ability to change that was removed from tonic.

In order to handle multiple codecs, switching based on the content-type header I'd speculate that the best way to do that would be:

• Change the Codec trait to be able to emit the content-type header suffix it supports, e.g for Json it can be Some("json"), for protobuf it can be None or Some("proto")

 fn content_type(&self) -> Option<&str>;

• Tonic code can use that to append the type to application/grpc when sending a message or enable switching on which codec to use on the server side.
• At that point you should be able to either manually construct the service code or work on changing the codegen to be able to support multiple codecs

Please note though that I am not a maintainer of tonic so this is just my view on one such way to accomplish what you want to but if you want such a change to be included in tonic you'll probably need to speak with Lucio or one of the other maintainers and see if they'd be open to such a change.