What is client-side streaming in gRPC?
Client-side streaming in gRPC sends many requests and gets one response. Learn the proto syntax, half-closing, and use cases like chunked uploads.
Expected Interview Answer
Client-side streaming is a gRPC pattern where the client sends a stream of many request messages and the server replies with a single response after it has read them all.
It is declared in the .proto with the stream keyword on the request type only: rpc Method(stream Request) returns (Response). The client writes messages one by one over a single HTTP/2 stream, then half-closes to signal it is done; the server processes the incoming sequence and returns one summarising response. This suits uploads, batching, and aggregation — sending file chunks, streaming metrics to be averaged, or bulk-inserting records — where many inputs collapse into one result.
- Uploads large or chunked data without one huge message
- Aggregates many inputs into a single result
- Constant client memory instead of buffering everything
- Ordered delivery over one HTTP/2 stream
- Supports deadlines, cancellation and flow control
AI Mentor Explanation
Client-side streaming is like a batter facing a full over: ball after ball is bowled and each outcome is recorded, and only at the end of the six deliveries does the scorer announce the over's total. Many individual events stream in, and one summary comes out. A client-streaming RPC works the same way — the client sends a sequence of request messages and the server replies once with the aggregated result.
Step-by-Step Explanation
Step 1
Declare the stream
In the .proto write rpc UploadChunks(stream Chunk) returns (UploadSummary); with stream on the request type only.
Step 2
Generate code
Regenerate stubs so the client gets a writable stream and the server handler receives a readable request stream.
Step 3
Stream requests from the client
Loop and call stream.Send(chunk) for each message, then call CloseAndRecv() to half-close and await the reply.
Step 4
Read the stream on the server
Loop calling stream.Recv() until io.EOF, aggregating or persisting each incoming message.
Step 5
Return one response
After EOF, send the single summarising response with SendAndClose(), ending the call with OK status.
What Interviewer Expects
- Many requests, one response is stated clearly
- Knowing stream sits on the request type only in proto
- Understanding the client half-close before the reply
- Good use cases like uploads and aggregation
- Awareness of ordering, deadlines and flow control
Common Mistakes
- Putting stream on the response side by mistake
- Expecting a response before the client finishes streaming
- Confusing it with server-side or bidirectional streaming
- Forgetting to half-close so the server never returns
- Buffering all requests in memory instead of processing incrementally
Best Answer (HR Friendly)
“Client-side streaming is when the client sends the server many messages in a row and the server waits, then gives back one combined answer at the end. It is perfect for things like uploading a file in chunks or sending lots of data to be totalled up.”
Code Example
service UploadService {
// A stream of requests, one response
rpc UploadChunks(stream Chunk) returns (UploadSummary);
}
message Chunk {
bytes data = 1;
}
message UploadSummary {
int64 total_bytes = 1;
}func (s *server) UploadChunks(stream pb.UploadService_UploadChunksServer) error {
var total int64
for {
chunk, err := stream.Recv()
if err == io.EOF {
return stream.SendAndClose(&pb.UploadSummary{TotalBytes: total})
}
if err != nil {
return err
}
total += int64(len(chunk.Data))
}
}Follow-up Questions
- What does half-closing the stream mean for the client?
- How does the server know the client is finished?
- When would you pick client streaming over repeated unary calls?
- How is flow control handled while streaming requests?
- How does this differ from bidirectional streaming?
MCQ Practice
1. In client-side streaming, how many messages flow each way?
The client streams many request messages and the server returns a single response.
2. Where does the stream keyword go in the proto method?
Client streaming marks only the request: rpc M(stream Req) returns (Resp).
3. Which is a strong use case for client-side streaming?
Streaming many chunks up to be assembled into one result is a classic client-streaming case.
Flash Cards
What is client-side streaming? — A stream of many client requests, then one server response.
Proto syntax? — rpc M(stream Req) returns (Resp);
How does the server get the reply out? — After EOF it calls SendAndClose with one response.
Best use cases? — Chunked uploads and aggregating many inputs.