Challenge 2: Design a Client-Streaming Addition — Possible Solution
====================================================================

// order.proto addition
service OrderService {
  rpc CreateOrder(CreateOrderRequest) returns (Order);
  rpc WatchOrderStatus(WatchOrderStatusRequest) returns (stream OrderStatusUpdate);
  rpc ImportOrders(stream CreateOrderRequest) returns (ImportSummary);
}

message ImportSummary {
  int32 orders_created = 1;
}

// Server implementation
function importOrders(call, callback) {
  let count = 0;

  call.on('data', (createOrderRequest) => {
    database.createOrder(createOrderRequest);
    count++;
  });

  call.on('end', () => {
    callback(null, { orders_created: count });
  });
}

WHY THIS WORKS AS AN ANSWER
------------------------------
rpc ImportOrders(stream CreateOrderRequest) returns (ImportSummary);
uses the stream keyword on the REQUEST type, not the response — the
exact syntax shape Chapter 4 established for client streaming: MANY
messages in from the client, ONE response out. Reusing the existing
CreateOrderRequest message means each streamed item has the same
shape as a normal single order creation, which is a reasonable design
choice since the underlying data being submitted is identical either
way.

The server implementation follows the event-driven pattern client-
streaming handlers use: a 'data' listener processes EACH incoming
request as it arrives (incrementing a counter here, though a real
implementation would also insert into the database), and only once
'end' fires (meaning the client has finished streaming) does the
handler send back the single ImportSummary response — exactly
matching "many requests streamed... one response at the end" from
Chapter 4's definition.