Server streaming có làm API nhanh hơn không? Có và không. Bài này đo thật: server tạo 10 item mỗi cái 50ms. Unary bắt client chờ 529ms mới nhận được gì; server streaming đẩy item đầu sau chỉ 58ms — nhanh hơn 9 lần về time-to-first-item. Nhưng tổng thời gian gần như bằng nhau (529 vs 533ms). Streaming không rút ngắn tổng — nó thắng ở độ trễ item đầu, bộ nhớ, và xử lý song song.
Hai kiểu streaming còn lại của gRPC. Bài này chạy thật: client streaming upload 5 chunk (1024+2048+512+4096+256) rồi server gộp trả đúng 7936 byte trong một response; bidirectional gửi số và nhận bình phương ngay lập tức, xen kẽ (3→9, 5→25, 8→64, 10→100). Kèm cái bẫy deadlock kinh điển của bidi: nếu gửi và nhận cùng một goroutine, cả hai cùng chờ nhau và treo.
Cần log, đo thời gian, và xác thực cho mọi RPC — nhưng không muốn lặp code ở từng handler. Interceptor là lời giải: một lớp bọc quanh mọi call. Bài này chạy thật một chain hai interceptor: logging đo thời gian mỗi call (Fast 1µs, Slow 46ms), và auth chặn /Secure khi thiếu token (trả Unauthenticated, handler không chạy) nhưng cho qua khi token đúng. Viết một lần, áp cho toàn hệ.
Một call không có deadline là một quả bom hẹn giờ: nếu server treo, client chờ mãi, tài nguyên cạn dần. Bài này chạy thật: server handler tốn 500ms, client đặt deadline 100ms — call bị huỷ sau đúng 101ms (không phải 500ms), client nhận DeadlineExceeded, và server phát hiện context bị huỷ nên dừng việc ngay thay vì tốn CPU cho kết quả client đã bỏ. Deadline lan truyền toàn chuỗi call qua context.
Trả về error là một chuỗi text thì client phải đoán xem có nên retry không, lỗi do input hay do server. gRPC có bộ status code chuẩn giải quyết điều đó. Bài này chạy thật: server trả InvalidArgument kèm details có cấu trúc (field nào sai), NotFound, và OK; client đọc code để quyết định tự động — retry với Unavailable, bỏ với InvalidArgument. Code là ngôn ngữ chung máy hiểu, hơn hẳn một dòng text.
Viết vòng lặp retry bằng tay ở từng chỗ gọi là lặp code và dễ sai. gRPC có retry policy khai bằng cấu hình. Bài này chạy thật: server fail 2 lần đầu với Unavailable rồi OK — client cấu hình retry tự thử lại và nhận thành công sau đúng 3 lần gọi server (đo bằng counter thật), với backoff tăng dần. Nhưng lỗi InvalidArgument thì không retry: server chỉ bị gọi 1 lần, vì gọi lại input sai vẫn sai.