grpc organization in microservices

Question

I'm creating a system using a microservices architecture. There are two microservices A and B, each living in their own repository.

There is a user.proto file containing protobuf definition and gRPC method signatures. A uses generated user.pb.go as a server. B uses user.pb.go as a client (of A).

One way to structure this is with proto definition appearing in A, with B having a code dependency on A:

 A
 ├── pb
 │   ├── user.proto
 │   └── user.pb.go
 └── service.go
 B
 └── service.go

B-->A

Another way is to have another repo P containing the proto definitions, with A and B depending on the new repo:

 A
 └── service.go
 B
 └── service.go
 P
 ├── user.proto
 └── user.pb.go

A-->P
B-->P

Or the new repo could contain the proto file only, with generated code in both A & B:

 A
 ├── service.go
 └── pb
     └── user.pb.go
 B
 ├── service.go
 └── pb
     └── user.pb.go
 P
 └── user.proto

What's the better approach here?

Answer 1

If your team does not prefer monorepo, I think the third option is the most suitable. 1 repo for the proto files. Then, it can be included as git submodule to A and B (if you are using git). A and B can have their own protoc script and the generated protobuf files depend on the programming languages they are using.