【问题标题】:Should gRPC server and client be in the same repository? [closed]gRPC 服务器和客户端应该在同一个存储库中吗? [关闭]
【发布时间】:2019-12-22 13:35:55
【问题描述】:

我正在使用 Go 使用 gRPC 服务器, 我了解 gRPC/Protobuf 的好处之一是您可以使用它通过使用服务器代码中使用的相同消息/服务 API 轻松创建客户端库。

如果我正在为我的服务实现一个客户端库,它显然需要导入服务代码和 API,所以我最终会有一个服务、一个服务器和一个客户端组件。在生产级代码中 - 所有这些组件是否应该存在于同一个存储库中并且仅由 go 包分隔?该服务是否应该是它自己的存储库并作为任何希望为该服务实现服务器/客户端库的人的依赖项?

【问题讨论】:

  • 正确的大写是“gRPC”,而不是“GrPC”

标签: go protocol-buffers grpc proto grpc-go


【解决方案1】:

所有这些组件是否应该存在于同一个存储库中并且是 仅由 go 包分隔?

各种 gRPC 组件不需要都存在于同一个 repo 中。

服务是否应该是它自己的存储库并作为对 有人希望为该服务实现服务器/客户端库吗?

我使用以下回购组织:

  • myapp-proto (common repo; git 标记并由客户端和 服务器)
  • 我的应用程序客户端
  • myapp-service1
  • myapp-service2
  • myapp-service3

例如,从各种数据源(REST API、MySQL、LDAP 等)提取数据的几个 gRPC 服务 - 这些服务器 gRPC 服务中的每一个都存在于它们自己的存储库中。有一个 gRPC 客户端包也存在于它自己的存储库中。为了保持变更控制的健全,常见的 proto 定义(和生成的 go 代码)存在于单独的单个 repo 中。

上述设置利用git version tagginggo modules 确保客户端和所有服务器都使用兼容版本的gRPC 消息/服务。向 gRPC proto 添加方法/字段可以独立于客户端/服务器部分完成 - 并在成熟时分阶段进行。

【讨论】:

    【解决方案2】:

    根据我的经验,最好的方法是将原型定义和生成的文件保存在服务器上。我通常将它们放在{SERVER}/pkg/grpc 中,然后根据您的项目结构将它们导入客户端{CLIENT}/internal/services/{SERVER}/grpc 或类似的东西中。

    【讨论】:

      猜你喜欢
      • 2019-08-25
      • 2020-04-03
      • 2022-06-29
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2011-01-27
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多