应将gRPC服务器和客户端放置在同一个存储库中吗？

在IT行业这个发展更新速度很快的行业，只有不停止的学习，才不会被行业所淘汰。如果你是Golang学习者，那么本文《应将gRPC服务器和客户端放置在同一个存储库中吗？》就很适合你！本篇内容主要包括##content_title##，希望对大家的知识积累有所帮助，助力实战开发！

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

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

解决方案

各种 gRPC 组件不需要全部位于同一个存储库中。

我使用以下存储库组织：

• myapp-proto（通用存储库；git 标记并由客户端和 服务器）
• myapp-client
• myapp-service1
• myapp-service2
• myapp-service3

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

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

终于介绍完啦！小伙伴们，这篇关于《应将gRPC服务器和客户端放置在同一个存储库中吗？》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！