grpc-gateway 与 Twirp RPC 有什么区别

Question

我们已经有了提供 rpc 和 rest 端点的Twrip-RPC 。那么为什么我们需要 grpc-Gateway。与 twirp 相比，它提供了哪些优势。是不是我们可以为 grpc 网关提供自定义端点是唯一的区别。Twrip-rpc 不能做什么 grpc-gateway？

Answer 1

Twirp 和 gRPC 网关类似。他们都从 protobuf 文件定义中构建 API 服务。

主要区别：

• gRPC 仅在 HTTP2 上使用 protobuf，这意味着浏览器无法轻松地直接与基于 gRPC 的服务通信。

• Twirp 在 Protobuf 和 JSON、HTTP 1.1 和 HTTP2 上工作，因此任何客户端都可以轻松通信。

• gRPC 是一个具有许多功能的完整框架。很强大的东西。

• Twirp 很小很小。只有一些基本功能，但它更容易管理。

• 
  

Answer 2

要使用 Go RPC 的 RPC 框架生成 RPC 脚手架，我们可以从一开始就考虑 gRPC 或寻找更简单的 Twitch RPC，即Twirp。

选择 Twirp 而不是 gRPC 的常见原因如下：

• Twirp 带有 HTTP 1.1 支持。

• Twirp 支持 JSON 传输。

• gRPC 在 net/http 之外重新实现了 HTTP/2。

gRPC over Twirp 的原因是：

• gRPC 支持流式传输。

• gRPC 做出了电线兼容性承诺。

• 网络级别的更多功能。

Answer 3

除了二进制 Protobuf 编解码器之外，Twirp 还支持 JSON 编码的请求和响应，但它仍然充当 RPC。POST您可以在端点上使用 HTTP ，例如/twirp/MyService/SayHello使用 JSON 有效负载并接收 JSON 响应。除了可选的 JSON 之外，与标准 gRPC 非常相似。

对于 gRPC 网关，它有点不同。在这里，您可以在现有 gRPC 服务上配置任何 HTTP REST 端点。例如，MySevice.SayHello可以映射到GET /hello. 这使得在 gRPC 定义之上实现完整的 REST 服务变得非常容易。

希望这能澄清一下。