【发布时间】:2020-08-11 17:06:09
【问题描述】:
我非常相信组合优于继承以及库优于框架(这与组合极为相似,因为库是组合的)。来自 gRPC java 示例的这段代码在某种程度上告诉我,java-grpc 是一个框架,而不仅仅是一个库(这很好,没有错)......
Server server = ServerBuilder.forPort(port)
.addService(new GreeterImpl())
.build()
.start();
我正在尝试让我的网络服务器(webpieces)接收这些 url 上的请求
- https://host/grpc -> webpieces 只会重新使用 grpc 库(希望)进行编码/解码
- https://host/json/{grpcMethod} -> webpieces 会抓取 grpcMethod 并将 json 解码为 grpc 对象以在此处调用服务
(根据第一个答案进行更清晰的编辑)...
关键点 -> Json 应该进来并使用相同的 protobuf 对象。我不应该像在这个 json grpc blow post JSON grpc
中看到的那样创建 json pojo我真的需要一个可以与之交互的 java-gRPC api,这样我就可以要求库在两个方向上进行编码/解码。这让客户可以选择在我们的公共 API 上执行 gRPC,或者如果他们愿意,可以使用 JSON。
我开始考虑使用 java-grpc,这是不可能的,因为它是一个框架而不仅仅是一个库(我的意思是它当然也是一个库,但因为我必须插入它而不是使用它,所以它是也是一个框架)。
我今天确实花了很多时间开始创建一个新的 io.grpc.ServerProvider 和一个新的 io.grpc.ManagedChannelProvider 但是哇,实现的方式比我想象的简单编码/解码要多得多这些对象是我一直在寻找的。p>
最后一个问题也是因为 gRPC 超过了 http/2。我在 java-grpc 中的客户端或服务器中没有看到提供应该命中的 url 路径的位置?
webpieces 实际上支持像 gRPC 这样的双向流式传输(http 前端 100% 支持它)。我们需要做一些工作来将其驱动到我们将在某个时候执行的控制器中(此时,我们可以在我们设置的同一个无服务器服务器上提供网页、gRPC 和 JSON)。
奖励点:像旧的“java”playframework 这样的 Webpieces 在开发时也支持热编译,所以如果我们可以在 webpieces 下使用 gRPC 服务器而不是 gRPC 服务器位于顶部,从而消除不重启开发,那将是非常理想的我们继续。
感谢您提供的任何提示! 院长
【问题讨论】: