Imagine you want to stream multiple protobuf message types from a server to the same client. There are different ways to design the streaming service, e.g. assuming I want to stream 3 different types of messages, for example notifications, states and events:
Option 1 - One stream per type
rpc StreamingService {
rpc NotificationStream(NotificationStreamingRequest) returns (stream Notification);
rpc StateStream(StateStreamingRequest) returns (stream State);
rpc EventStream(EventStreamingRequest) returns (stream Event);
}
Option 2 - One stream for all types
rpc StreamingService {
rpc Stream(Request) returns (stream Message);
}
message Message {
oneof type {
Notification notification = 1;
State state = 2;
Event event = 3;
}
}
While Option 1 would offer a cleaner implementation for the services in the code, Option 2 seems like the better option for communication systems. But is there any actual overhead in Option 1 other than the additional header and trailer metadata that now gets send multiple times due to multiple streams?
In the Performance Best Practices of the official gRPC website it is only mentioned to use streaming RPCs for long-lived data flow to avoid continuous RPC initiation, and to create a separate channel for each area of high load, which would actually favor Option 1 if each stream has a high load, because then each stream could use its own gRPC channel.
There is also nothing mentioned in the Performance best practices with gRPC from the MS Docs that really speaks against Option 1, other than the maximum limit of concurrent streams on servers.
Does anything really speak against Option 1 and using multiple streams in the same client-server connection? Is there any real performance disadvantadge on a technical level when having multiple streams?
