gRPC 和普通 HTTP API 哪个更适合 APP 客户端与服务器通信？为什么大部分 APP 都还在使用传统 HTTP API？

[drymonfidelia]

[drymonfidelia]

@drymonfidelia #60 /t/1013792 /t/1040867

[jeesk]

首先，大多数应用程序的架构是先有网页，再进行服务器交互，因此大部分接口都是基于 REST HTTP 的设计。为了让 gRPC 支持网页调用，通常需要使用 gRPC-Gateway 或 gRPC-Web 来实现 Web 和 gRPC 协议之间的转换。那么问题来了，为什么谷歌不将所有网页接口设计为使用 gRPC-Web 调用呢？为什么不将文件上传也改为使用 gRPC （这里打个比方，手动狗头，大家自行想象）？

如果我是架构师，我的项目从一开始就是这样设计的，我是否会直接选择 gRPC ？项目成员是否会对此提出异议？这是否会被视为一种不合理的设计？

使用 gRPC 带来了哪些好处？

项目的开发过程往往是先发现问题，再寻找解决方案。

那么架构师会发现哪些问题？

1. 双向通信太麻烦， 要么使用 websocket 要么使用 http2, 有没有替代品？
2. 对多语言适配 sdk 太繁琐了， 能不能为多语言混合直接生成 sdk, 增加请求体的约束减少人力投入文档和 sdk 的编写？
3. 对性能和带宽以后一定要求



架构师在这个时候考虑到，Protocol Buffers （ protobuf ）作为一种跨平台的交互协议，可以为每种语言生成不同的 schema ，并返回 protobuf 的流式数据。这样，即使使用 HTTP 也能实现高效的交互。谷歌正是看到了这一点，于是基于 protobuf 和 HTTP/2 开发了 gRPC 这一规范性框架。通过 CI 工具为不同平台生成各种语言的 schema ，同时为网页生成通用的库。


上面这些东西是不是太超前？


1. 大部分是小企业， 一般就会固定开发语言，不可能出现一家公司 go, java, nodejs, ruby, cpp, python 来相互调用 sdk .
2. 对外提供的接口太少，小公司可能连文档都没有，都是口头约定。 即是接口多，直接使用 swagger 之类的 openapi 生成一份 http 文档即可，根本不需要投入太多的人力去编写不同语言的文档和 sdk,
3. 业务也没有双向通信的场景。
4. 网关使用 gzip 、Zstd 也能够达到节省带宽。

我就问一问，你是架构师你会怎么选？ 没有需求强上需求？

[TORYOI]

不要把简单的问题复杂化了

[KiraMaple]

@jeesk #40 gRPC 基于 HTTP2 ，不是所有浏览器都完全支持 HTTP2 的，虽然现在绝大互联网产品都是基于较新的浏览器设计了，但是一些政企部分的客户端系统可能会很老。在更早时候，这个情况更严重，所以 gRPC 在早年更适合服务器之间通信，现在也就形成了路径依赖。

[jeesk]

@KiraMaple

grpc 在浏览器使用需要 grpc-web 或者 grpc-gateway , 不支持 http2.0 根本无所谓.

[KiraMaple]

@chaleaochexist gRPC 中的 RPC ，Remote procedure call 翻译作远程过程调用，RPC 概念的提出初衷就是期望像调用本地接口一样远程调用其他服务上的接口。protobuf 作为一个序列化工具，为了支持 gRPC 也支持定义服务和服务中的接口，用来生成调用方的代理调用接口。最开始 gRPC 使用回调的方式达到本地调用的编码体验，但这样容易陷入回调地狱。后来某些编程语言中退出了类似 await/async 等机制，才解决了回调地狱。这样的体验和调用本地接口的编码体验几乎无异，除了你知道这是异步和需要 await 关键字。
HTTP 经过封装也是可以达到效果的，说到底，gRPC 是基于 HTTP2 结合了 protobuf 、通信、RPC 等功能的一个更上层的 SDK ，如果你是期望达到 RPC 的编码体验，既然有 gRPC 珠玉在前，何必自己用裸 HTTP 再造轮子。

[KiraMaple]

@jeesk #65 那可能我的知识过时了，我接触 grpc 的时候都是好多年前，后面也没有长期使用，当时确实是需要浏览器有 HTTP2 支持

[lizy0329]

@SmiteChow 啊哈哈哈，别捅破了