Bidirectional streaming lets a gRPC client and server exchange message streams over one opened connection. Both sides can continue sending messages, supporting asynchronous communication instead of repeated request-response calls. section 1.1.5 section 2.5.2
Choose bidirectional streaming when the interaction requires ongoing traffic in both directions:
- Use it to send multiple client requests continuously while the server returns result objects as a stream. section 2.5.2
- Prefer it over repeated pagination or unary calls when an open connection can deliver data progressively and reduce communication delay. section 1.1.5 section 1.2
- Track each asynchronous operation with a unique identifier so failures can be associated with the correct request. section 2.5.2
- Account for browser limitations: REST remains broadly supported, while browser-facing gRPC deployments may require a gRPC Web proxy. section 1.2
Streaming payment creation
A payment client streams payment requests to a service while the service streams back operation results. Because responses may complete asynchronously, each request should carry or receive an identifier that distinguishes failures and statuses. section 2.5.2
service Payment {
Create(stream CreatePaymentRequest)
returns (stream CreatePaymentResponse){}
}
A protobuf service declaration expresses bidirectional streaming by marking both the request and response as streams. section 2.5.2
