展开讨论

skywhopperHN来源作者
经验与复盘经验摘录 · 机器翻译

我参与的一个项目基本上就是一个用于将JSON文档共享到多个其他系统的系统。

… 我参与的一个项目基本上就是一个用于将JSON文档共享到多个其他系统的系统。当时是在一个使用Go语言的公司，使用AWS。我们本来可以用一个S3存储桶。但当然，一个API可能也不错，这样以后你可以添加自定义的认证层，或者添加服务器端的过滤和查询功能。所以我们用几周时间构建了一个REST API。但然后技术主管觉得我们没有像其他团队的酷孩子那样使用gRPC，这让我们感到内疚。如果我们需要一个Python客户端，以便我们可以构建一个Ansible插件来调用这个API呢？（我的意思是，Ansible插件可以是任何语言；它是一个REST API，Ansible已经支持调用这个API（或者你也可以直接使用curl）；或者你只需用三行代码就能写出必要的Python来调用REST API。）所以我们花了几个月的时间转换到gRPC，但我们需要使用Connect库，因为它更酷，但结果发现它不支持GET请求，而且公司里其他人都没有使用它。

源讨论gRPC：糟糕的部分原帖 223 条评论 · 导入时统计
2

社区评论 0

还没有社区评论，来聊聊你的看法。

原讨论中的回复 2

仅展示本次导入中包含的直接回复。中文为机器翻译，可查看英文原文。

TH
thinkharderdevHN

> 最糟糕的是，大多数人并不需要gRPC，但还是用了它。这只会增加复杂性，你很可能得不到实际的好处。我见过无数个简单的REST API，用语言原生的工具构建，最后被烧毁，换成了一层又一层的gRPC垃圾，这需要学习多种新工具和DSL，更难排查和调试，最终会导致API的僵化，比健康的状态要早得多。 这对我来说听起来很奇怪，因为我不太明白gRPC怎么会引发这些问题？ > 一层又一层的gRPC垃圾 哪些层？从REST（可能是JSON over http）切换到gRPC不应该引入任何新的“层”。它只是用另一种方式的API调用替换了原来的方式。 > 学习多种新工具和DSL 新工具肯定是有的，你需要protoc或者buf来从IDL生成绑定，但你需要学习的新DSL是什么？…

完整原文
DA
DandyDevHN

人们使用它——就像我一样——因为相比REST，它提供了更好的类型安全性。我们在$dayjob中使用gRPC，我讨厌回到JSON over REST那种字符串类型的混乱，或者GraphQL那种极其复杂且过度设计的陷阱。gRPC让我们能够轻松地构建类型安全、自我文档化的内部API，并且使用Buf之类的工具，大部分的痛苦都被隐藏了。 我认为DSL是一个优点。如果你构建REST API，通常也会使用DSL来定义你的API，至少如果你想要轻松生成客户端的话。但在这个情况下，DSL是OpenAPI，这是一种由YAML或JSON规范组成的容易出错的混乱东西。

完整原文
在 Hacker News 阅读

尊重不同观点，分享具体经验。

登录后即可发帖、评论、转发和引用。