我们已经有了提供 rpc 和 rest 端点的 Twrip-RPC。 那么为什么我们需要 grpc-网关 .与 twirp 相比，它提供了什么优势。就像我们可以为自定义端点提供 grpc 网关一样，唯一的区别就是。Twrip-RPC不能做的grpc网关是什么？
Twirp 和 gRPC gateway 是相似的。它们都从 protobuf 文件定义构建 API 服务。
主要区别：
- gRPC 仅通过 HTTP2 使用 protobuf，这意味着浏览器无法轻松地直接与基于 gRPC 的服务通信。
- Twirp 适用于 Protobuf 和 JSON、HTTP 1.1 和 HTTP2，因此任何客户端都可以轻松通信。
- gRPC 是一个具有许多功能的完整框架。非常强大的东西。
- Twirp又小又小。只有一些基本功能，但管理起来要容易得多。
要使用 Go RPC 的 RPC框架生成 RPC 脚手架，我们可以从一开始就考虑 gRPC，或者寻找更简单的 Twitch RPC，即 Twirp。
选择 Twirp 而不是 gRPC 的常见原因如下：
- Twirp 附带 HTTP 1.1 支持。
- Twirp支持出门的JSON传输。
- gRPC 在 net/http 之外重新实现 HTTP/2。
gRPC 优于 Twirp 的原因是：
- gRPC 支持流式处理。
- gRPC 做出线路兼容性承诺。
- 网络级别的更多功能。
Twirp除了支持二进制Protobuf编解码器之外，还支持JSON编码的请求和响应，同时它仍然表现为RPC。您可以在具有 JSON 有效负载的终端节点(如/twirp/MyService/SayHello(上使用 HTTPPOST，并接收 JSON 响应。与标准 gRPC 非常相似，但可选 JSON 除外。
对于 gRPC 网关，情况略有不同。可在此处，可以在现有 gRPC 服务上配置任何 HTTP REST 终结点。例如，MySevice.SayHello可以映射到GET /hello。这使得在 gRPC 定义之上实现完整的 REST 服务变得非常容易。
希望这能澄清一下。