Should gRPC server and client be in the same repository?

Question

I am playing around with a gRPC server using Go, I understand that one of the benefits of gRPC/Protobuf is that you can use it to create a client library easily by using the same messages/service API that are being used in the server code.

If I am implementing a client library for my service, it obviously needs to import the service code and API, so I would eventually have a service, a server, and a client components. In production grade code - should all of these components exist in the same repository and be separated only by the go packages? Should the service be its own repository and serve as a dependency to anyone wished to implement server/client libraries for the service?

Answer 1

should all of these components exist in the same repository and be separated only by the go packages?

The various gRPC components do not need to all live in the same repo.

Should the service be its own repository and serve as a dependency to anyone wished to implement server/client libraries for the service?

I use the following repo organization:

• myapp-proto (common repo; git tagged and used by both client and server)
• myapp-client
• myapp-service1
• myapp-service2
• myapp-service3

For example, several gRPC services which pull data from various datasources (REST APIs, MySQL, LDAP etc.) - each of these server gRPC services live in their own repos. There is a single gRPC client package that also lives in it's own repo. And to keep change-control sane, the common proto definitions (and generated go code) lives in a separate single repo.

The above setup leverages git version tagging and go modules to ensure the client and all the servers are using the compatible versions of the gRPC messages/services. Adding methods/fields to the gRPC proto can be done independent of the client/server pieces - and phased in when mature.

Answer 2

In my experience what has worked best is to keep the proto definition and generated files with the server. I typically put them in {SERVER}/pkg/grpc and then import them in client {CLIENT}/internal/services/{SERVER}/grpc or something similar depending on your project structure.