gRPC — альтернатива REST API от Google

Проблема

Когда мы разрабатываем приложение, которое разделено на независимые автономные компоненты, мы говорим о микросервисной архитектуре. Для взаимодействия компонентов используется API. Самый популярным API является REST. Это обусловлено его гибкостью, эффективностью (в большинстве сценариев) и тем, что он легко масштабируется. 

Большая часть реализаций REST использует стандарт JSON для обмена сообщениями. Обычно это удобно — сама по себе такая структура легко читается людьми и предоставляет независимость от языка программирования.

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

Зачем нужен gRPC

gRPC (Remote Procedure Calls) — это система удалённого вызова процедур (RPC) с открытым исходным кодом, первоначально разработанная в Google. В качестве основного протокола передачи применяется HTTP/2, для описания процедур применяется “Protocol Buffers”. Это в свою очередь приносит дополнительные преимущества: сжатие HTTP-заголовков и мультиплексирование запросов.

gRPC предполагает возможность аутентификации, потоковой передачи данных в любую сторону, управление потоками, отмену и time-out запросов, при этом выделяется кроссплатформенностью за счет генерации исходного кода классов для всех популярных языков программирования. 

Когда использовать gRPC

Статистика говорит о том, что gRPC используется гораздо реже, чем REST. К сожалению, часто только из-за этого разработчики выбирают REST. И если в небольших проектах это оправдано, тогда напрашивается вопрос: в каких случаях правильным выбором всё же будет gRPC?

Стоит взглянуть на таблицу их основных отличий.

Хотя REST подход также может использовать HTTP 2 для обмена данными, тем не менее он будет ограничен моделью запрос-ответ, при которой не применяется поддержка двусторонней потоковой передачи данных возможной для HTTP При этом, конечно же сохраняется возможность унарных взаимодействий, которые реализует HTTP 1.1 (один запрос — один ответ).

В конечном итоге мы получаем более высокую скорость ответа в разных сценариях.

При этом в gRPC наименования полей, ожидаемых запросов и возвращаемых ответов определяется и описывается в одном месте — в файле .proto. И если вы хотя бы раз разрешали конфликты в наименовании полей вида ObjectID и object_id, то вам определенно понравится работать с gRPC.

Пример .proto файла:

syntax = "proto3";  /* Наименование пакета данных */  message Calculator {      int32 xxx = 1;      int32 yyy = 2;  }  message CalculatorRequest {      Calculator calculator = 1;  }  message CalculatorResponse {      int32 result = 1;  }  

Когда не использовать gRPC

gRPC при всех своих достоинствах не лишен недостатков. Вот парочка:

• Использование HTTP/2 в gRPC, что делает невозможным реализацию клиента gRPC в браузере — вместо этого приходится использовать прокси. 

• Более сложная отладка по сравнению с REST из-за бинарного обмена сообщениями

Реальный кейс

Как упоминалось выше, для работы с gRPC достаточно одного .proto файла.

Мы делали реализацию API на Python, где использовали дуплексное (двунаправленное соединение) для сервиса потокового распознавания речи в текст.

Дуплексное соединение gRPC на Python:

def stream_recorder(self) -> Union[RecognitionRequest, str]:      """Потоковый захват речи"""      for _ in range(0, int(self.rate / self.chunk * self.seconds)):          data = self.stream.read(self.chunk, exception_on_overflow=False)          yield RecognitionRequest(audio=data)  def stream_recognize(self) -> str:      """Потоковое распознавание речи"""      credentials = grpc.ssl_channel_credentials()      with grpc.secure_channel(f'{settings.SPEECH_SERVER}:{settings.SPEECH_PORT}',                              credentials=credentials) as chennel:          stub = VoiceAssistantServiceStub(chennel)          metadata = [('authorization', f'Bearer {settings.SPEECH_API_TOKEN}'), ('audioformat', 'lpcm')]          for response in stub.RecognizeAudio(self.stream_recorder(), metadata=metadata):              if response.chunks[0].final:                  return response.chunks[0].text.strip()  

Эти декларативные преимущества gRPC работают не только в момент написания кода. Особенно удобно делать отладку соединения в Postman, который предоставляет поддержку протокола. 

Даже не имея доступа к удаленному серверу мы можем имитировать запросы с моковыми данными и эмулировать ответ нажатием одной кнопки.

Выводы

В отличие от REST, gRPC — решение, которое не зависит от платформы и языка. И благодаря HTTP/2 и протоколу Protobuf решает проблемы, связанные со скоростью передачи данных, их весом, в результате повышая эффективность обмена сообщениями.