In my company, we have a system organized with microservices with a dedicated git repository per service. We would like to introduce gRPC and we were wondering how to share protobuf files and build libs for our various languages. Based on some examples we collected, we decided at the end to go for a single repository with all our protobuf inside, it seems the most common way of doing it and it seems easier to maintain and use.
I would like to know if you have some examples on your side ? Do you have some counter examples of companies doing the exact opposite, meaning hosting protobuf in a distributed way ?
Protocol buffers are a combination of the definition language (created in .proto files), the code that the proto compiler generates to interface with data, language-specific runtime libraries, and the serialization format for data that is written to a file (or sent across a network connection).
AWS Glue Schema Registry now supports Protocol buffers (protobuf) schemas in addition to JSON and Avro schemas. This allows application teams to use protobuf schemas to govern the evolution of streaming data and centrally control data quality from data streams to data lake.
Protocol Buffers (Protobuf) is a free and open-source cross-platform data format used to serialize structured data. It is useful in developing programs to communicate with each other over a network or for storing data.
gRPC is based on the idea of defining a service and specifying methods that can be called remotely with their parameters and return types. On the server-side, the server implements this interface and runs a gRPC server to handle client calls.
We have a distinct repo for protofiles (called schema
) and multiple repos for every microservice. Also we never store generated code. Server and client files are generated from scratch by protoc
during every build on CI.
Actually this approach works and fits our needs well. But there are two potential pitfalls:
schema
and microservice repositories. Commits to two different git repos are not atomic, so, at the time of schema
updates, there is always a little time period when schema
is updated, while microservice's repo is not yet. Go
, there is a potential problem of moving to Go modules introduced in Go 1.11. We didn't make a comprehensive research on it yet. Each of our microservices has it's own API (protobuf or several protobuf files). For each API we have separate repository. Also we have CI job which build protoclasses into jar (and not only for Java but for another language too) and publish it into our central repository. Than you just add dependencies to API you need.
For example, we have microservice A
, we also have repository a-api
(contains only protofiles) which build by job into jar (and to another languages) com.api.a-service.<version>
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With