The reason why gRPC streaming services can only have a single parameter - stream

Question

At the moment, gRPC service definitions can only have a single parameter even if it’s a streaming service which makes challenging to represent the “initial” request. For instance, consider a chat app in which a user can join a chat room.
In this case, the domain can be modelled as follows.
message JoinRoomRequest {
required string room = 1;
}
message ChatMessage {
required string content = 2;
}
A consumer of the chat app would send a join request and start a bi-directional stream of messages, so the service can be described in this way.
service SimpleChat {
rpc joinChatRoom (JoinRoomRequest, stream ChatMessage) returns (stream ChatMessage);
}
However, in gRPC the above syntax is not valid. The only way to represent the described chat service is
service SimpleChat {
rpc joinChatRoom (stream ChatMessage) returns (stream ChatMessage);
}
What is the reason behind this decision, and how a similar domain can be modelled in gRPC?

Answer 1

Simplicity. It is much easier to model a request/response as a single payload rather than varadic, especially in your case, where you want the multiplicity to be different - what, for example, would it mean to take
(A, stream B, C, stream D)
And... if you can take multiple elements, can you return multiple too? Many languages support that concept, after all.
No, it is much easier to receive (as either input it output) either a request or a stream of requests of a single type.
In your scenario, perhaps consider the request type being a thing wrapper over a oneof (discriminated union) of all the actual expected messages, and just have your code enforce that the first one is a "join":
message ChatRequest {
oneof RequestType {
JoinRoomRequest join = 1;
ChatMessage message = 2;
}
}
And take a stream of ChatRequest