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

[dengtongcai]

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

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

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

[qiyuey]

IDL 的 RPC 都有这些问题

[bobuick]

grpc 跨语言上优势. dubbo 实现一份, 客户端, 服务端都能用来解码和传输层协议通用. 你各自来一份 python, go, cpp, php 你试试看 dubbo 会还有多少事需要做进去的

[Raymon111111]

那想跨语言没别的办法了吧?

[index90]

你用什么框架不需要序列化和反序列化啊？

不明白你究竟面临什么问题。我猜，可能你原来的逻辑代码依赖了你自定义的 Message 对象，现在要转成 ProtoMessage 而已。

[mango88]

全部 json 一把梭

[brucewuio]

跨语言就方便咯

[Cbdy]

json 一把梭

[guolaopi]

@index90 +1.
而且转成 grpc model 和客户端把 grpc 解析成可序列化 model 的文件不都是 grpc 生成的吗？客户端服务端直接调用就行了？还是说 java 和 C#不一样， 这些玩意儿要手写？

[linxl]

grpc 是服务端写起来麻烦点(不过我也没用过别的 rpc), 客户端使用起来是真舒服, 只要服务端把 protobuf 注释写好点(当作客户端的文档), 基本上也不用再写什么文档了.

[wysnylc]

spring cloud 是推荐使用 Restful

[chendy]

RPC 都是这个流程吧，而且有 IDL 还能生成，裸 http+json 的还要自己写数据类
核心逻辑没有这些多可能是因为业务简单吧，业务简单业务代码可能都没有 SQL 代码多…

[passerbytiny]

请用 RESTful，或者叫做原始 HTTP。

[dengtongcai]

@wysnylc
@passerbytiny
我也很无奈，应该是这家公司的历史问题，全都是 grpc

[passerbytiny]

好吧，我粗略查了一下，grpc 谷歌出的。谷歌出品，除非你的产品打算服务几十亿人，否则别给自己找麻烦。

[iPhoneXI]

dubbo 其他语言的客户端还是个渣吧

[iPhoneXI]

@iPhoneXI 我觉得 thrift 挺好的，成熟，支持多语言

[laminux29]

grpc、thrift 这些框架的优势就是，根据数据结构的定义，自动生成代码。

然而你却说 [核心逻辑代码量都没这些转换的代码多] ？？？？

就好比，你用美团外卖，然后来吐槽自己跑了很远去取外卖，很累很远；或者是找了女朋友，却吐槽说自己天天撸管太累。

[Moming]

用 gRPC 不都配套 ProtocolBuffer 吗？为什么你还要自己处理序列化问题？

不过我真不习惯 Java 的项目管理，还是 cargo 爽……

[reus]

你水平太低

[danielmiao]

不应该自己封装一层通用转换么？？？涉及到接口的不做通用化的处理不是给自己找麻烦么