I think if you're using a monorepo then you almost certainly want to have just a single copy of each .proto file, and let multiple projects depend on that single version. That is how we do it within Google and it seems to work pretty well for us. If you make multiple copies then that would seem to defeat the purpose of having a monorepo anyway.
Could you elaborate on what kind of Bazel build speed problem you're running into if you go with the approach of just using a single copy? It might be that you just have to set things up to avoid unnecessary dependencies. I would recommend keeping .proto files small by breaking up large ones--this way a target that depends on a particular .proto file will not have to be rebuilt as often. Likewise it is a good idea to have one proto_library Bazel target per .proto file. On Thu, Jun 14, 2018 at 11:49 PM a lobster <[email protected]> wrote: > Our team uses a big mono repo like google. All microservices are a > separate folder and placed in the same repo. The following shows the > directory structure of one of our microservices: > service/main/identify > ├── cmd > ├── conf > ├── dao > ├── http > ├── modelOur team uses a big mono repo like google. All microservices are > a separate folder and placed in the same repo. The following shows the > directory structure of one of our microservices: > > service/main/identify > ├── cmd > ├── conf > ├── dao > ├── http > ├── model > ├── proto<here is *.proto and *.pb.go> > ├── rpc > │ ├── client > │ └── server > └── service > > Previously we used HTTP communication. Now we plan to migrate to grpc, but > we don't know how to store proto files in each microservices. Now we think > of two options: > 1, copy > Manage the proto file by copying. If service A depends on service B, then > service A needs to copy all proto files of service B into their own > directory and generate the code. There is no direct interdependence between > each service. A little copying is better than a little dependency. > 2, dependent > Each project exposes its own proto folder, relies on the proto folder, and > manages permissions and builds through Bazel, but this greatly reduces > Bazel's build speed when there are too many > proto dependencies. > So if it is yours, how will you choose? What are the reasons? > > ├── proto<here is *.proto and *.pb.go> > ├── rpc > │ ├── client > │ └── server > └── service > > Previously we used HTTP communication. Now we plan to migrate to grpc, but > we don't know how to store proto files in each microservices. Now we think > of two options: > 1, copy > Manage the proto file by copying. If service A depends on service B, then > service A needs to copy all proto files of service B into their own > directory and generate the code. There is no direct interdependence between > each service. A little copying is better than a little dependency. > 2, dependent > Each project exposes its own proto folder, relies on the proto folder, and > manages permissions and builds through Bazel, but this greatly reduces > Bazel's build speed when there are too many > proto dependencies. > So if it is yours, how will you choose? What are the reasons? > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/protobuf. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
