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

Question

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

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

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

• https://host/grpc -

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

关键点-

我真的需要一个可以与之交互的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服务器置于顶部，从而消除我们正在进行的无重启开发，那将是非常理想的。

谢谢你的建议迪恩

Answer 1

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

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

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