客户端与服务端通信使用 GRPC 有什么劣势吗？

[HanMeiM]

如题，之前都是安卓和 IOS 基本都是通过 HTTP 的形式与服务端通信的
想了解下如果使用 GRPC 通信的话会有什么劣势吗？
因为接口定义可以直接通过 protobuf 来定义，避免前后端之间频繁的沟通接口字段细节，感觉挺方便的。

[shoaly]

感觉老哥混着在说, 如果不想用 http 换成 grpc , 通常用 grpc 是为了解决 http 只能单向通信的问题, 也就是从 http 降级成为 tcp, 支持双向通信了..... 和消息报文格式没关系
再说报文编码, json 和 protobuff, 其实 protobuff 的申明方式确实有一些优势, 能解决报文中各种字段 , 但是需要前后端都认可把, 如果前端同事还是愿意 json 哈索, 也无可厚非, 因为 json 格式调试起来, 人眼更直观

[jorneyr]

高负载时负载均衡比较麻烦。

[xuanbg]

也没啥，就是需要客户端支持 gRPC 而已。。。用 http 呢，就不需要考虑这个问题。

[Macolor21]

graphql 更适合

[letitbesqzr]

调试麻烦

[joesonw]

@jorneyr nginx 和 traefik 都支持 grpc 请求级别的负载均衡.

[thevita]

1. 最大的劣势就是会不停有人问："为什么不用 http"
2. 调试确实不方便，工具链+人员培训

[oneegg]

Grpc 和 http2 的关系

[thevita]

其实如果只是为了解决 "频繁的沟通接口字段细节", 可以一步步来比如
1. protobuf-over-http
2. 用 gRPC-Gateway, grpc 和 rest 共存

[mxT52CRuqR6o5]

如果只用 grpc 通信，以后如果要做 web 端，就得再写一份 http 版本的
而且 http 对接各种 cdn 不会有问题，grpc 接入就可能有限制

[iugo]

做 Web 开发和小程序开发会麻烦, 前后端均需要 (可参考 gRPC Web) 做额外的操作.

[HanMeiM]

protobuf-over-http
其实有想过，我知道 web 前端有相关的开源项目，但是客户端我不清楚有没有
而且也没打算写 web ，计算写 web ，那多半是官网，和客户端的代码可以不重合

[zoharSoul]

我试过 android 上的, 还挺方便.
pb 文件放到对应目录就自动编译生成代码了. 比 go 的体验好多了

[kwanzaa]

劣势就是你要说服人。