Skip to main content
2026-07-29 16:01
gRPC

Server Streaming

StreamParseValidateMedium
Try Interactive Demo

What you will learn

  • Four stream kinds (unary, server-stream, client-stream, bidi) each have distinct cancellation semantics — test the cancel path for each
  • Backpressure: slow consumer must not OOM the server — measure memory as the stream fills, not just end-to-end latency
  • Half-close: client sends END_STREAM to signal 'no more messages', then reads server replies — your client must handle this distinctly from full close

Description

Receive a stream of order updates from the server (server → client streaming).

Test Scenario

// grpcurl server streaming
grpcurl -plaintext \
  -d '{"id": "order-123"}' \
  localhost:50051 \
  practice.orders.OrderService/TrackOrder

// Receives multiple messages:
{"orderId": "order-123", "status": "processing", "message": "Order received"}
{"orderId": "order-123", "status": "shipped", "message": "Order shipped"}
{"orderId": "order-123", "status": "delivered", "message": "Order delivered"}
// Stream ends

Testing Tips

  • •Server sends multiple responses
  • •Client reads until stream ends
  • •Good for real-time updates, logs
// Playwright API Testing - gRPC (via REST gateway)
import { test, expect } from '@playwright/test';


test('gRPC unary call via gateway', async ({ request }) => {
  const response = await request.post('/api/grpc/UserService/GetUser', {
    data: { id: '1' }
  });


  expect(response.ok()).toBeTruthy();
  const data = await response.json();
  expect(data.user).toBeDefined();
});

Challenge ID: grpc-server-streaming

2 frameworks available