我可以使用JavaGRPC作为库而不是框架吗？

我非常相信组合而不是继承，以及库而不是框架（这与组合非常相似，因为库是组合的）。这段来自GRPCJava示例的代码在某种程度上告诉我，JavaGRPC除了只是一个库之外，还是一个框架（这很好，没有错）

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

• ->webpieces将（希望）重新使用grpc库进行编码/解码
• {grpcMethod}->webpieces将获取grpcMethod并将json解码到grpc对象中，以在此处调用服务

（根据第一个答案进行编辑以获得更清晰的答案）

Key Point->Json应该使用相同的protobuf对象。我不必像这篇json grpc blow post中所看到的那样创建json pojo

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

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

今天我确实花了很多时间开始创建一个新的io.grpc.ServerProvider和一个新的io.grpc.ManagedChannel Provider，但哇，实现的方法比我想象的要多得多，因为我只需要对这些对象进行编码/解码，这就是我一直在寻找的

还有最后一个问题，因为gRPC是通过http/2的。我在java grpc的客户机或服务器中没有看到提供应该命中的url路径的位置

webpieces实际上支持双向流，就像gRPC一样（http前端100%支持）。我们有一些工作要做，以将其驱动到控制器中，我们将在某一点上执行这些操作（在这一点上，我们可以在设置的同一台无服务器服务器服务器上为web页面、gRPC和JSON提供服务器）

优点：像旧的“java”playframework这样的Webpieces在开发时也支持热编译，因此，如果我们可以在Webpieces下使用gRPC服务器，而不是将gRPC服务器置于顶部，那么这将是非常理想的，可以消除我们正在进行的无重启开发

谢谢你给我的建议！

---

院长

我仍然认为gRPC更像一个图书馆

无论如何，这将使您了解如何序列化和反序列化请求/响应。此外，它还向您展示了如何手动提供MethodDescriptor和ServerServiceDefinitions来定义方法和服务，包括路由

---

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

其实我之前也读过这篇文章。我正试图弄明白如何使用相同的protobuf生成的实体，这样我就可以用protobuf实体而不是这些gson实体对同一代码执行json和grpc。我真的非常感谢您的帮助！我在那篇文章中遇到的一个症结是，它没有在我的帖子“webpieces将获取grpcMethod并将json解码到grpc对象中以在这里调用服务”中提到这句话。相反，这篇文章要求我创建可以来回转换到json的“bean”。我真的希望在gRPC protobuf通信和json通信中为每个bean使用“一”实体。哦，不过upvote表示支持！也许我正在尝试做的事情还不可行，或者至少在不进行大量反思的情况下不容易，等等，我更愿意避免。你有我可以遵循的twitter手柄吗？到目前为止，你帮了大忙。希望我可以使用热编译/不重新启动gRPC服务器，而不是现有的gRPC服务器。我们喜欢创建没有服务器重启的java快速开发平台。很高兴这有帮助，但我不做twitter。热重新加载听起来很有趣。我不知道你怎么能很快做到。iirc，protoc不支持增量编译。如果您只考虑webpieces，这可能是可行的

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