17

I couldn't find any "Best Practices" online for usage of gRPC and protobuf within a project. I'm implementing an event-sourced server side app. The core defines the domain aggregates, events and services without having external dependencies. The gRPC server calls the core services passing in request objects which eventually translates into events being published. Events are serialized using protobuf and published on the wire. We're currently in a dilemma on whether our events should be the protobuf generated classes directly, or should we keep the core and events separate and implement a mapper/serializer layer to translate events between protobuf <-> core

If there's another approach we're not considering, please guide us :)

Thanks for the help.

hsen
  • 435
  • 5
  • 13

2 Answers2

8

Domain Model Objects and Data Transfer Objects (Protobuf Message) should be separated as much as possible. For this the best way is to transform your Domain Model Objects into Google Protobuf Messages and vice versa. We've made a protobuf-converter to make it extremely simple.

Roman Gushel
  • 121
  • 3
  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - [From Review](/review/low-quality-posts/12314858) – Mike May 11 '16 at 11:17
  • 1
    Mike, I hope this answer will be alive forever http://stackoverflow.com/questions/11773552/protocol-buffer-and-oo-design/37158427#37158427 – Roman Gushel May 11 '16 at 11:25
  • @Mike: Given that the question asks for an approach, and the answerer has outlined the approach along with the link, I would not classify this as a "link-only" answer. See http://meta.stackoverflow.com/questions/287563/youre-doing-it-wrong-a-plea-for-sanity-in-the-low-quality-posts-queue – gariepy May 11 '16 at 15:05
  • Would you say this impacts the Golang implementation equally? – Angad May 08 '18 at 13:00
  • I would say yes. If you are familiar with why ViewModels should be separated from Domain models. Similar idea applies here. – FailedUnitTest Dec 31 '19 at 09:56
1

Protobufs are really good for serialization and backwards compatibility, but not so good at being first class Java objects. Adding custom functionality to protos is currently not possible. You can get a lot of the benefits by using Protobufs at the stub layer, wrap them in one of your event Pojos, and pass them around internally as such:

public final class Event {
 private final EventProto proto;

 public void foo() {
   // do something with proto.
 }
}

Most projects don't change their .proto file that often, and almost never in a backwards incompatible way (neither wire nor API). Having to change a lot of code because of proto changes has never been a problem in my experience.

Carl Mastrangelo
  • 5,970
  • 1
  • 28
  • 37