对比
优点
- 支持强类型模式定义（有点类似Typescript），更严格的规范、proto文件可以从端到端生成消息和客户端代码。
- 高性能，比JSON快5倍
- Protocol Buffers 是一种非常高效的二进制编码格式，体积更小
- gRPC构建在 HTTP/2之上，可以提供大规模的高性能基础
- 安全性，二进制编码格式不可读
- gRPC Streaming：gRPC 本身支持长期实时连接，通常称为
streams. 流对于聊天、观察或块数据传输等情况很有用
- 跨平台和跨语言：gRPC支持多种编程语言和平台
- gRPC 允许客户端指定他们愿意等待 RPC 完成的时间。截止时间被发送到服务器，服务器可以决定如果超过截止时间要采取什么操作。例如，服务器可能会在超时时取消正在进行的 gRPC/HTTP/数据库请求。
缺点
- 传输的数据的结构需要在 proto 文件中定义，需要维护 .proto 或 .json 描述符文件，每次参数的变更都需要维护此文件（gRPC提供了代码自动生成工具，可以自动生成客户端和服务端的代码，省去了手动编写代码的过程）
- 浏览器支持有限，需要使用gtRPC-web/protobuf-ts，Envoy、Nginx代理（具体参考下面实现部分）
- 不可读的，内置的JSON转换可以提供方法，可以在调试时设置。
- gRPC 使用每个消息的大小限制来管理传入和传出消息。 默认情况下，gRPC 将传入消息限制为
4 MB
- 用例少
推荐场景
- 微服务：gRPC 专为低延迟和高吞吐量通信而设计。gRPC 非常适合效率至关重要的轻量级微服务。
- 点对点实时通信：gRPC 对双向流具有出色的支持。gRPC 服务可以实时推送消息，无需轮询。
- 多语言环境：gRPC 工具支持所有流行的开发语言，使 gRPC 成为多语言环境的不错选择。
- 网络受限环境：gRPC 消息使用 Protobuf（一种轻量级消息格式）进行序列化。gRPC 消息始终小于等效的 JSON 消息。
- 进程间通信 (IPC)使用 gRPC 进行进程间通信：IPC 传输（例如 Unix 域套接字和命名管道）可与 gRPC 一起使用，以便在同一计算机上的应用程序之间进行通信
在以下场景中，建议使用其他框架而不是 gRPC：
- 浏览器可访问的 API：浏览器不完全支持 gRPC。gRPC-Web 可以提供浏览器支持，但它有局限性并引入了服务器代理。
- 广播实时通信SignalR：gRPC 支持通过流式传输进行实时通信，但不存在将消息广播到注册连接的概念。例如，在聊天室场景中，新的聊天消息应发送到聊天室中的所有客户端，每个 gRPC 调用都需要单独将新的聊天消息流式传输到客户端。
对于这种情况来说是一个有用的框架。SignalR 具有持久连接的概念和对广播消息的内置支持。
gRPC-web
实现踩坑很多坑，最后在Vite下无法获取参数，找到protobuf-ts解决方法
gRPC 在前端運作最大的問題，就是前端對於 gRPC 所使用的 protocol 不是那麼完好的支援，現在主流瀏覽器使用
HTTP1.1，而 gRPC 使用的是更加高效的HTTP2。Google 提供的解決方案是利用一個 proxy 架設在後端，將前端所有的 HTTP1.1 流量轉換成 HTTP2。
Uncaught ReferenceError: exports is not defined
grpc/grpc-web/issues/1242
Aymeric-Henry/GRPC-Vite-TS-Svelte
错误
Connect 是一系列用于构建浏览器和与 gRPC 兼容的 HTTP API 的库：您编写一个简短的Protocol Buffer架构并实现您的应用程序逻辑，Connect 生成代码来处理编组、路由、压缩和内容类型协商。它还以任何受支持的语言生成惯用的、类型安全的客户端
- Connect 服务器和客户端支持三种协议：gRPC、gRPC-Web 和 Connect 自己的协议。
- Connect 是我们对生产级 RPC 的愿景。它简单、可靠且不引人注目
grpcurl
fullstorydev/grpcurl
grpcui
fullstorydev/grpcui
ERROR [ExceptionsHandler] 1 CANCELLED: Call cancelled
grpc/grpc-node/issues/2233
