GRPC流媒体服务只能具有一个参数的原因

Question

目前，GRPC服务定义只能具有一个参数，即使它是流媒体服务，这使得表示"初始"请求具有挑战性。例如，考虑一个聊天应用程序，用户可以在其中加入聊天室。

在这种情况下，可以按以下方式对域进行建模。

message JoinRoomRequest {
  required string room = 1;
}
message ChatMessage {
  required string content = 2;
}

聊天应用程序的消费者将发送加入请求并启动双向消息流，因此可以以这种方式描述该服务。

service SimpleChat {
  rpc joinChatRoom (JoinRoomRequest, stream ChatMessage) returns (stream ChatMessage);
}

但是，在GRPC中，上述语法无效。表示描述的聊天服务的唯一方法是

service SimpleChat {
  rpc joinChatRoom (stream ChatMessage) returns (stream ChatMessage);
}

该决定背后的原因是什么，以及如何在GRPC中建模类似的领域？

Answer 1

简单性。将请求/响应建模为单个有效载荷而不是varadic，尤其是在您的情况下，您希望多重性与众不同，这要容易得多。/p>

(A, stream B, C, stream D)

和...如果您可以 多个元素，您也可以返回多个元素吗？毕竟，许多语言都支持该概念。

否，接收(作为输入IT输出(要么更容易或单一类型的请求流。

在您的情况下，也许认为请求类型是所有实际实际预期消息的oneof(歧视联合(的包装器，并且只需使您的代码强制执行第一个是一个'加入"：

message ChatRequest {
  oneof RequestType {
    JoinRoomRequest join = 1;
    ChatMessage message = 2;
  }
}

并进行ChatRequest