Kar*_*lek 3 protocol-buffers grpc
我有一个像这样的 gRPC API 定义(来自 Akka 文档示例),但更长(4000 行只是一部分service)。
service GreeterService {
rpc SayHello (HelloRequest) returns (HelloReply) {}
rpc ItKeepsTalking (stream HelloRequest) returns (HelloReply) {}
rpc ItKeepsReplying (HelloRequest) returns (stream HelloReply) {}
rpc StreamHellos (stream HelloRequest) returns (stream HelloReply) {}
}
Run Code Online (Sandbox Code Playgroud)
但是,RPC 列表现在变得太长,我想以某种方式将其“分解”为多个文件,以便该文件更具可读性。像这样的东西
// file 1:
service GreeterServicePartA {
rpc SayHello (HelloRequest) returns (HelloReply) {}
rpc ItKeepsTalking (stream HelloRequest) returns (HelloReply) {}
}
// file 2:
service GreeterServicePartB {
rpc ItKeepsReplying (HelloRequest) returns (stream HelloReply) {}
rpc StreamHellos (stream HelloRequest) returns (stream HelloReply) {}
}
// main proto file:
import "file1"
import "file2"
service GreeterService = GreeterServicePartA + GreeterServicePartB
Run Code Online (Sandbox Code Playgroud)
即使只是在不同的文件中单独定义 RPC,然后编写如下内容也会对我有所帮助:
service GreeterService {
rpc SayHello = importedSayHello
rpc ItKeepsTalking = importedKeepsTalking
rpc ItKeepsReplying = importedKeepsReplying
rpc StreamHellos = importedStreamHellos
}
Run Code Online (Sandbox Code Playgroud)
是否有可能以某种方式在 gRPC 原型定义中“组合”服务?
你不应该有这么大的服务。如果增长到 4000 行,听起来就像是所有方法的垃圾场。我希望其中大部分是文档...通常我希望有更多基于更大 API 子集的服务。例如,假设我有 MyAndroidAppService,它可能会成为垃圾场。但我可以将其设计为 MyAndroidAppConfigService、MyAndroidAppNotificationService、MyAndroidAppChatService(假设一个非常复杂的应用程序有很多方法)。
但既然你已经有了这样的服务,你能做什么呢?您不能将定义拆分service为多个文件。如果将服务定义拆分为多个新服务,则会破坏 gRPC 的线路兼容性。
The most you can do is move the message definitions to a separate file and then use the normal import mechanism. Since moving messages to a different file can cause API incompatibilities in generated code, you can use import public "path/to/messages.proto" instead.
| 归档时间: |
|
| 查看次数: |
7290 次 |
| 最近记录: |