grpc gateway 存在的意义是什么

一套代码两套运行机制, 比如团队里对 GRPC 很熟悉, 并且基于此搭建了整套服务, (甚至可能客户端和服务端通信使用 rpc)

这时候三方想要和你们合作, 给你们 1kw, 让你们暴露 HTTP 接口分享资源给他们, 直接开发一套 HTTP 肯定麻烦, 直接用 grpc-gateway 包装一层, 写文档给他们用

@seth19960929 你这个假设不太实际啊, 真给我 1kw 我绝逼单独开发一套...保准让客户满意.

@chaleaochexist 太真实存在了, 单独开发一套绝对不是这么简单的
1. 项目太复杂, 老项目已经运行了好几年
2. 时间太赶, 需求方要你下周提供
3. 1kw 给的不是你, 给的是公司, 你只需要提供最快的实现方式

@chaleaochexist 你再单独开发一套，是不是就同时维护了两份代码？有考虑过可维护性么？

而且，即使团队想全用 GRPC ，也不可避免地会遇到只能使用 HTTP 的场景，比如内网用 lua 调用接口

本质就是一套代码, 提供两种调用方式,
你所说的 BFF, 是指启一个 HTTP 服务, 然后内部连接 rpc, 代理一层?
那你为何这样做, grpc-gateway 就是这样的一个标准解决方案

@seth19960929 代理一层 是因为 rpc 提供的服务是不考虑 客户端实际场景的, 是站在自己人内部调用的角度.

如果是考虑外部调用的话, 我就不会用 grpc 了. 不知道我表达的是否清晰.

@seth19960929 或者说为什么会有人一开始用 grpc 开发一套系统给外部调用?

@mooyo 有道理!!!

@chaleaochexist #6 你搜一下, 挺多物联网用的, 我认识的一个做儿童音箱的公司就在用

不用 gateway ，你让切图仔直接传 protobuf ？

我也纠结，如果一开始就有支持 web 的需求，是不是不应该选择 grpc ，
如果不需要流式的话直接 jsonrpc 还简单方便，
有什么方案支持 web 还支持流式常用的？

为了偷懒省事啊

@fuzzsh 下载前端早就不是切图仔了, 用 json-web
另外如果是和前端配合, 后端一开始就不可能用 grpc.


@seth19960929 大佬你指的是哪句话 "挺多物联网用的(什么?),"

下载 --> 现在
json-web --> grpc-web

@chaleaochexist #13 可能没表达清楚, 你说 rpc 只在内部使用, 物联网公司有在用, 音箱(客户端)和服务端通信用的 rpc

@seth19960929 音箱置一片？

@seth19960929 明白, 所以当后续有新的第三方需要 http 的场景的时候, 就是 grpc-gateway 大放光彩的时候了?

受教, 多谢.

@roundgis 普通音箱我不太了解, 做的是智能音箱
@chaleaochexist #17 我 #1 楼的回答就差不多是这个意思

@chaleaochexist grpc-gateway 应该保持轻量，只做协议转换，看中的是高兼容性，bff 更强调的 API 聚合能力，当然 bff 里也可以做协议转换，但两者不冲突。

协议定好。服务治理方便。

我们的后端服务没有 http ，都是 grpc ，bff 层是由前端 node 维护。
但是后端也有一些对外 API 的场景，比如外部 vendor 回调以及多地区跨机房互调。这些都是走公共的 gateway 转发，不额外维护 http 服务。

内部全写 grpc ，在网关+中间件+转 http 。服务之间互相调用。

这东西很没用，我直接代码层面一个函数转换就能搞定。这东西还要走两遍 http2 ，设计就有问题。