В каких случаях стрим-запросы в gRPC предпочтительнее одинарных?

Когда использовать стримы вместо одинарных запросов

В gRPC есть четыре типа взаимодействия: одинарный запрос-ответ (unary), серверный стрим, клиентский стрим и двунаправленный стрим. Выбор зависит от характера данных и требований к задержке и пропускной способности.

Стримы полезны, когда данные поступают непрерывно или большими порциями, и их неудобно упаковывать в один ответ. Например, при передаче логов, потокового видео, метрик с датчиков или при реализации чата. Они также позволяют начать обработку до получения всех данных, снижая задержку.

Одинарные запросы проще и подходят для операций, где нужен один ответ: получение пользователя по ID, выполнение транзакции, проверка статуса. Они легче в отладке и не требуют управления состоянием соединения.

Практический пример

Представьте сервис аналитики, который принимает события от клиентов. Если использовать unary, клиент должен собрать все события и отправить одним запросом, что неудобно при большом потоке. Лучше использовать клиентский стрим:

service Analytics {
  rpc SendEvents(stream Event) returns (Summary);
}

message Event {
  string type = 1;
  int64 timestamp = 2;
  string payload = 3;
}

message Summary {
  int32 count = 1;
}

Клиент может отправлять события по мере их появления, а сервер агрегирует их и возвращает итог. Это снижает нагрузку на память и позволяет обрабатывать данные в реальном времени.

Вывод

Используйте стримы, когда данные непрерывны, объемны или требуют асинхронной обработки. Для простых запросов с одним ответом оставайтесь на unary — это проще и предсказуемее.