Как стать автором
Обновить

Комментарии 16

А можете про плюсы/минусы grpc написать?

Да, напишу
Плюсы
  • В 2 раза компактнее JSON;
  • В 3 раза компактнее XML;
  • Не читается по сети
  • Меньше требует CPU и памяти на десериализацию
  • Доступно для всех языков
  • “Умная” обратная совместимость

Минусы
  • Низкая скорость по http;
  • Нет гибкого описания OpenAPI.
Раскройте мысль, что значит «Низкая скорость по http»?
У grpc-gateway менее быстрая скорость по http, в сравнении с другими серверами на GO. Потому что у нас сначала идет вызов по http, потом происходит маршелинг, потом вызов gRPC, и потом все тоже самое, но уже в обратную сторону
Если бы вы использовали нативные типы, то было бы компактнее ещё раза в 3-4.
Передавать текст по grpc, конечно, интересно. Но само по себе большого смысла не имеет.
Http вообще не имеет к grpc отношения. Это технология http2. Попытки передать grpc по устаревшим протоколам приносят результат, но не стоит от них ждать прорывной производительности.
Скажите, вот генерится два сервера: json rest api и grpc. Можно обращаться как через gateway так и напрямую к grpc? А в каких случаях куда ходить лучше?
Кстати не на всех языках есть grpc, на Perl его нет, кроме какого то старого, давно не поддерживаемого модуля.

Да, оба способа доступны для обращения. gRPC лучшее по выше перечисленным критериям. Но если язык клиента не поддерживает gRPC, то он может использовать более привычный протокол http

Возможно не тема для конкретно этой статьи, но: зачем этот overhead с лишним сервисом grpc-gateway, если клиенты REST API работают по HTTP 1 и по факту ресурсов будет потребляться больше? Так имеет делать смысл, если фронтенд тоже использует gRPC (есть «промышленные» примеры WebUI на нем?). А у нас вот просто «эффективные» project манагеры приняли такое решение (везде grpc-gateway) именно потому что swagger и еще пару grpc interceptor прикручены, для лога и авторизации запросов (можно ли текущему пользователю использовать тот или иной запрос или нет). А WebUI использует просто HTTP 1.
Например, в нашей компании мы при обновлении API на 2ю версию, сразу завезли туда gRPC и все SDK перевели, конечно же, на него. А REST остался, тк он более привычен простым пользователям, особенно не разработчикам.
А по-поводу того что у вас. Я согласен, что использовать этот подход, не имея ввиду дальнейшее внедрение и переключение всех сервисов на gRPC, это не самое разумное использование ресурсов системы.
Если нет возможности аргументировать это Вашим менеджерам, я бы тогда все же предложил посмотреть в сторону того, как тогда использовать этот подход на все 100%.
Например, в нашей компании мы при обновлении API на 2ю версию, сразу завезли туда gRPC

Было бы неплохо это сразу в статье отразить. А то у меня впечатление, что наши «эффективные» project манагеры просто зацепились за фразу, что gRPC — это круто, и пошло-поехало…

Скорее всего)

А кто у Вас основные потребители API? Я имею ввиду browser client или приложение какое?

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

Генератор потдеживает 3 версию swagger aka openapi?

На сегодняшний день, нет
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории