1

We're using GRPC extensively in a project, using the Grpc.Tools package to generate .Net clients from the .proto definition files. However, we have a headache in that the generated code is very tightly coupled with GRPC - it has GRPC specific attributes, GRPC specific interfaces and so on.

What I'm after is a way to generate "clean" interfaces in C#/.Net, i.e. plain C# types and interfaces to describe the service and messages, that can be cheaply referenced without bringing along all the GRPC stuff.

Are there any existing libraries/tools out there that you've had good experiences with? Or any example projects I can look at that deal with this issue neatly? Or perhaps an example of customising the GRPC tooling to extract what I'm after from it?

RichardW1001
  • 1,985
  • 13
  • 22

2 Answers2

1

There are a few things to know here:

  • gRPC C# itself is serialization format agnostic (= you can use any serialization format you want), but because without a serialization format, the usability is limited, the Google Protocol buffers are supported as the default choice. The Grpc.Tools package provides the protocol buffer compiler plugin, which generates service stub that are to be used with Protobuf + gRPC (so the "tight coupling" you're mentioning is intended).

  • If you want to use your own serialization format, you basically need to write your own code generator (and gRPC C# API is designed in a way that this is possible) that will generate classes/interfaces that will look the way you want. In fact, if you inspect the Grpc.Core nuget package (the main functionality of gRPC C#), you'll see that it doesn't have any dependency on Google.Protobuf whatsoever, which allows you to use serialization format of choice. Please note that this is a pretty advanced concept and I would strongly recommend just using the default option (i.e. gRPC with prototobuf, using the standard codegen) unless you know what you are doing.

  • There are projects that have successfully implemented a custom codegen for different serialization formats such as Apache Thrift, Flatbuffers, Microsoft Bond etc. You can inspect their code to see how to write a custom codegen (there are also several blogposts around on this topic).

Jan Tattermusch
  • 1,515
  • 9
  • 9
  • My point is rather that I'd like message classes that don't inherit from some framework type, and a reasonable interface that I can use... implementation details like that should be kept away from the rest of the codebase, and the code that's generated by the default tooling doesn't help with that. – RichardW1001 Oct 24 '18 at 22:23
  • RichardW1001, providing a generated interface is problematic for backward compatibility - If you add new methods to your service definition in .proto file (which is pretty common as your service evolves), that would generate an interface with an extra method in it and all implementations of that interface would break. Instead, grpc codegen generates an abstract class with default method implementations, which avoids this problem (after regenerating, everything still builds fine). – Jan Tattermusch Nov 06 '18 at 07:19
1

Currently, there are no such libraries. Even protobuf.net is not compatible with grpc (Using ProtoBuf-net with gRPC)

What I'm after is a way to generate "clean" interfaces in C#/.Net, i.e. plain C# types and interfaces to describe the service and messages, that can be cheaply referenced without bringing along all the GRPC stuff.

That is the most significant advantage of the grpc that based on proto file code is generated in multiple languages. I agree with you that generated code could look better, and interfaces should be created for client/server/messages.

If you don't want to use generated code, then you can create your custom client implementation, other parts (server, messages) must be used from generated code.

Adam Łepkowski
  • 2,048
  • 1
  • 24
  • 41