Что такое gRPC?
gRPC (Google Remote Procedure Call) — это современный фреймворк для удаленного вызова процедур. Проще говоря, это способ для программ общаться друг с другом, как если бы они вызывали локальные функции.
Ключевые отличия от REST:
- Контракт: Вместо документации Swagger используется строго типизированный файл
.proto. - Формат данных: Вместо текстового JSON используется бинарный Protobuf, что гораздо быстрее и компактнее.
- Транспорт: Работает поверх HTTP/2, который поддерживает мультиплексирование (несколько запросов в одном соединении) и стриминг.
REST vs gRPC: Наглядное сравнение
REST (JSON / HTTP/1.1)
Текстовые данные, новое соединение на каждый запрос.
gRPC (Protobuf / HTTP/2)
Бинарные данные, одно постоянное соединение.
Контракт: .proto файл
Файл с расширением .proto — это сердце gRPC. Он описывает все доступные сервисы, их методы, а также форматы сообщений (запросов и ответов). Это единственный источник правды об API.
syntax = "proto3";
package rickandmorty;
service CharacterService {
rpc GetCharacter(CharacterRequest) returns (CharacterResponse);
}
message CharacterRequest {
int32 id = 1;
}
message CharacterResponse {
string name = 1;
string status = 2;
string species = 3;
}
Типы вызовов
gRPC поддерживает четыре типа взаимодействия клиента и сервера.
Unary (Унарный)
Классический запрос-ответ. Аналог обычного REST-вызова.
Server streaming
Клиент отправляет один запрос и получает поток ответов.
Client streaming
Клиент отправляет поток запросов и получает один ответ.
Bidirectional streaming
Клиент и сервер обмениваются потоками данных независимо друг от друга.
Работа в Postman
Postman позволяет удобно работать с gRPC. Главное — импортировать .proto файл, и Postman сам построит интерфейс.
Message
Metadata
Стратегии тестирования
Тестирование gRPC фокусируется на контракте, данных и поведении стримов.
Позитивные сценарии
- Проверка всех полей в ответе на корректные типы данных, согласно
.proto. - Тестирование с разными валидными значениями в запросе.
- Для стримов: проверка, что приходят все ожидаемые сообщения и поток закрывается корректно.
Негативные сценарии
- Отправка сообщения с неверным типом данных (например,
"id": "abc"вместо123). - Отправка запроса без обязательных полей.
- Проверка кодов ответа gRPC (например,
INVALID_ARGUMENT,NOT_FOUND,PERMISSION_DENIED). - Тестирование дедлайнов: что будет, если сервер не ответит за указанное время.
