gRPC — это высокопроизводительная универсальная платформа удаленного вызова процедур (RPC) с открытым исходным кодом, созданная Google и получившая популярность как выбор для создания клиент-серверных приложений.
В течение последних нескольких лет я выступал за использование gRPC в сервис-ориентированных архитектурах (SOA) в нескольких стартапах, главным образом из-за обещания низкой задержки и использования HTTP/2.
Несмотря на множество преимуществ использования gRPC, у него есть и обратная сторона, скрытая за завесой оптимистичной документации и примеров.
«gRPC — это современная высокопроизводительная платформа удаленного вызова процедур (RPC) с открытым исходным кодом, которая может работать в любой среде».
Выше первая вступительная строка с веб-сайта gRPC (на момент написания статьи). Основное внимание уделяется двум ключевым преимуществам: высокой производительности и возможности работы в любой среде. Это звучит фантастически! И, безусловно, выполняет обещание, если вы посмотрите на документацию и примеры.
Но дьявол кроется в деталях…
gRPC, безусловно, эффективен, поскольку я испытал gRPC в нескольких производственных средах, а также провел тесты производительности, и я могу это подтвердить. Но то, действительно ли gRPC обеспечит более высокую пропускную способность (по сравнению, например, с JSON REST API), сильно зависит от варианта использования.
Наличие более высокой пропускной способности означает, что клиенты и серверы gRPC могут работать эффективно, что напрямую влияет на «стоимость обслуживания»💸 (и, конечно же, удобство для пользователей).
Однако в реальном сценарии пропускная способность — это только часть дела.
На момент написания (август 2023 г.) gRPC доступен только для использования с мобильными приложениями, и считается невозможным реализовать клиент gRPC для веб-браузеров (ссылка: Состояние gRPC в браузере, Йохан Брандхорст ). Это означает, что все веб-приложения должны будут использовать прокси-сервер для подключения к бэкэндам gRPC, добавляя дополнительный переход, а это означает, что весьма вероятно, что более высокий прирост пропускной способности будет потерян из-за прокси-сервера. Дополнительные накладные расходы, связанные с запуском и обслуживанием прокси-сервера, также снизят любые затраты на обслуживание экономии, полученной за счет высокой пропускной способности.
Может ли gRPC работать в любой среде, кроме веб-браузеров? Простой ответ - нет, это очень вводящее в заблуждение утверждение. Теоретически, когда условия соблюдены, да. Но реальность далека от этого.
В настоящее время (в августе 2023 г.) существует только 11 официально поддерживаемых языков, документация которых практически отсутствует или отсутствует. например По iOS нет документации, хотя предполагается, что это поддерживаемая платформа.
Даже если выбранный язык находится в списке поддерживаемых языков и скрестим пальцы 🤞, есть документация, нет гарантии, что сгенерированный код идиоматичен языку. Возьмем, к примеру, C++, поскольку стандарт Google C++ не генерирует исключений, в реализации сервера C++ не так много поддержки обработки исключений. Он даже проглатывает любые необработанные исключения и возвращает очень вводящий в заблуждение статус UNIMPLEMENTED.
Краткое содержание
При правильных условиях gRPC может быть очень мощной структурой, но это не что-то «нативное для Интернета» или даже идиоматическое для всех языков.
- В отличие от введения, приведенного на веб-сайте gRPC, gRPC нельзя использовать в любой среде (по крайней мере, без обходных путей).
- gRPC в основном подходит для связи между серверами, если используется с поддерживаемым языком, что, вероятно, изначально предназначалось для использования, а не в качестве универсальной инфраструктуры RPC.
- Несмотря на то, что существует (очень действительный) вариант использования gRPC в мобильных клиентах из-за задержки, отсутствие официальной документации затруднит начало работы.
Я выделил только некоторые проблемы, связанные с gRPC, но есть и преимущества использования gRPC. например Использование Protobuf для определений служб обеспечивает соблюдение контракта API, в отличие от использования чего-то вроде спецификаций OpenAPI.
🤔 Пища для размышлений, лучше ли использовать Protobuf поверх HTTP/2 вместо gRPC?
