时间戳

首页 > 解决方案 > 我可以将 java-grpc 用作库而不是框架吗？

java - 我可以将 java-grpc 用作库而不是框架吗？

问题描述

我非常相信组合优于继承以及库优于框架（这与组合非常相似，因为库是组合的）。gRPC java示例中的这段代码在某种程度上告诉我java-grpc是一个框架，而不仅仅是一个库（这很好，没有错）......

    Server server = ServerBuilder.forPort(port)
            .addService(new GreeterImpl())
            .build()
            .start();

我正在尝试让我的网络服务器（webpieces）接收这些 url 上的请求

（根据第一个答案进行编辑以提高清晰度）...

关键点 - > Json 应该进来并使用相同的 protobuf 对象。我不应该像在这个 json grpc blow post JSON grpc中看到的那样创建 json pojo

我真的需要一个可以与之交互的 java-gRPC api，这样我就可以要求库在两个方向上进行编码/解码。这让客户可以选择在我们的公共 API 上执行 gRPC，或者如果他们愿意，可以使用 JSON。

我开始考虑使用 java-grpc，这是不可能的，因为它是一个框架而不仅仅是一个库（我的意思是它当然也是一个库，但由于我必须插入它而不是使用它，它也是一个框架）。

我今天确实花了很多时间开始创建一个新的 io.grpc.ServerProvider 和一个新的 io.grpc.ManagedChannelProvider 但是哇，实现的方式比我想象的要简单地编码/解码这些对象要多得多我这就是我要找的。

最后一个问题也是因为 gRPC 超过了 http/2。我在 java-grpc 的客户端或服务器中没有看到一个位置来提供应该命中的 url 路径？

webpieces 实际上支持像 gRPC 这样的双向流式传输（http 前端 100% 支持它）。我们需要做一些工作来将其驱动到我们将在某个时候执行的控制器中（此时，我们可以在我们设置的同一台无服务器服务器上提供网页、gRPC 和 JSON）。

奖励积分：像旧的“java”playframework 这样的 Webpieces 在开发时也支持热编译，所以如果我们可以在 webpieces 下使用 gRPC 服务器而不是 gRPC 服务器处于顶部，从而扼杀我们正在进行的不重启开发，那将是非常理想的上。

感谢那里的任何提示！院长

标签： javajsongrpcgrpc-java

解决方案

我仍然认为 gRPC 更像是一个库。

无论如何，JSON 博客文章将为您提供如何序列化和反序列化请求/响应的好主意。此外，它还向您展示了如何手动提供 MethodDescriptors 和 ServerServiceDefinitions 来定义方法和服务，包括路由。

Protobuf 是 gRPC 的默认序列化。所以，使用 protobuf 要容易得多。您通常不需要担心那些低级 API。尽管如此，在核心中，它并不强烈依赖于特定的序列化，正如您从博客文章中看到的那样。

推荐阅读