grpc 真的不适合和 Java 一起使用

[dengtongcai]

服务端查询数据-->转成 grpc model-->响应给客户端-->客户端吧 grpc 解析成可序列化 model

把我整吐了，太浪费时间了，核心逻辑代码量都没这些转换的代码多，Java 程序员千万别用 grpc，还是老老实实 dubbo 等

纯吐槽，不知道有没有用过 grpc 的老铁有好的技巧分享一下

[OakScript]

@Moming rust 党可以

[iEverX]

如果业务逻辑是自己的类，那么就是需要写很多的 wrapper，并且 proto 类的确不适合直接用在业务代码里，thrift 好很多

[hsuehsen]

Java （如 spring ）自带的框架，自动把查询的数据转换成 json 格式，所以 java 技术栈用 rest api 基本都是不用自己封包数据的。但是，grpc 是要自己调用 protobuf 生成的接口进行处理

其实，可以将 java 自动产生的 json 通过 json2grpc 网关做转换的（我记得是有类似的框架）

[hsuehsen]

grpc 最大的优势是跨语言，是从整个系统层面（各种服务 /各种客户端），节省序列化反序列化的工作量与兼容性
特别是涉及多种通讯协议的情况下

[momocraft]

如果不需要多服务多语言 可能 grpc (以及 openapi protobuf 这些东西) 好处真的不大

[impl]

Java 真的不适合人类使用

[richard1122]

我们用 kotlin + grpc，感觉没什么问题。 楼主是说 build message 的那一个个 set 用起来很麻烦吗？

[qoras]

客户端和服务端交互用 http, 服务端内部交互用 grpc

[mreasonyang]

这种字段完全一样的数据结构转化当然是用 Mapstruct 来做啊

[friddle]

没懂。为啥服务端要解析成 model。服务端调用的是 http+json 吗。
当时我直接撸了个基于特定业务规则的 json 转 grpc 请求。一个拦截层就可以做到的事情。
需要可以把代码给你参考。不打算开源。因为业务还是绑定的太深。

还有 go 版本的 grpc-GateWay。这个也不错

[YzSama]

我以前用过 wsdl cxf 来写。和 其他服务端 C#\Python 还蛮匹配的