Protobuf / gRPC implementation #33
MartinSchmidt
started this conversation in
Polls
Replies: 2 comments
-
As I see it the A option is a bit more cumbersome as described in this overview, however it provides an expressive link between the code and the protobuf object. @guidmaster what is your immediate hunch on this choice ? |
Beta Was this translation helpful? Give feedback.
0 replies
-
Option A. To me it´s just data - it´s a contract between services. This is what we need to agree on and have discussions about. We should not force a specific implementation but let it be up to services to do what feels best for that specific implementation. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We have already discused that we want to use gRPC to communicate from the client to the registry.
As I can see, we have some options, , other
Option A - .proto files
First is to create .proto files containing the description of the messages and services that we will be exposing
Pros of doing .proto files is that it will be easier to create new clients in other languages, since we would not have to write the .proto files when we eventually get to it.
Cons: more work when creating an using classes and unwrapping, one must beware that it is classes so == is not the same as equals! Since classes == is by ref.
Option B - code-first
Second is to do a code-first approach, were we create the C# code first, annotate it with the propper attributes, to use.
Pros we get way cleaner code, since class instantiating an so on can all be done through constructors, and static create methods, without requiring to think about the details of the gRPC/protobuf spec when working with the classes.
Cons additional work when new clients are to be created, since we would then have to create .proto files, and maintain the code two places.
Option C - library based on .proto
Third options is to create a c# library that creates classes based on the .proto files and then extend or wrap these, although extending the classes is not recommended:
Google Protobufs are specifically not intended to be extended. Here's a paragraph from the documentation (in the middle of this: http://code.google.com/apis/protocolbuffers/docs/cpptutorial.html):
Protocol Buffers and O-O Design Protocol buffer classes are basically dumb data holders (like structs in C++); they don't make good first class citizens in an object model. If you want to add richer behaviour to a generated class, the best way to do this is to wrap the generated protocol buffer class in an application-specific class. ... You should never add behaviour to the generated classes by inheriting from them. This will break internal mechanisms and is not good object-oriented practice anyway.
3 votes ·
Beta Was this translation helpful? Give feedback.
All reactions