Полный набор gRPC, RESTful JSON API, WS и Swagger из одного proto файла. От введения до нюансов и тонкостей grpc-gateway

[beduin01]

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

[klim0v]

Да, напишу

[klim0v]

Плюсы

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

Минусы

• Низкая скорость по http;
• Нет гибкого описания OpenAPI.

[peresada]

Раскройте мысль, что значит «Низкая скорость по http»?

[klim0v]

У grpc-gateway менее быстрая скорость по http, в сравнении с другими серверами на GO. Потому что у нас сначала идет вызов по http, потом происходит маршелинг, потом вызов gRPC, и потом все тоже самое, но уже в обратную сторону

[Maksclub]

потом происходит маршелинг, потом вызов gRPC

как это сопоставляется с вашим пунктом из плюсов?

• Меньше требует CPU и памяти на десериализацию

[Warchoon]

Если бы вы использовали нативные типы, то было бы компактнее ещё раза в 3-4.
Передавать текст по grpc, конечно, интересно. Но само по себе большого смысла не имеет.
Http вообще не имеет к grpc отношения. Это технология http2. Попытки передать grpc по устаревшим протоколам приносят результат, но не стоит от них ждать прорывной производительности.

[dmrt]

Скажите, вот генерится два сервера: json rest api и grpc. Можно обращаться как через gateway так и напрямую к grpc? А в каких случаях куда ходить лучше?
Кстати не на всех языках есть grpc, на Perl его нет, кроме какого то старого, давно не поддерживаемого модуля.

[klim0v]

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

[nuklearlord]

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

[klim0v]

Например, в нашей компании мы при обновлении API на 2ю версию, сразу завезли туда gRPC и все SDK перевели, конечно же, на него. А REST остался, тк он более привычен простым пользователям, особенно не разработчикам.
А по-поводу того что у вас. Я согласен, что использовать этот подход, не имея ввиду дальнейшее внедрение и переключение всех сервисов на gRPC, это не самое разумное использование ресурсов системы.
Если нет возможности аргументировать это Вашим менеджерам, я бы тогда все же предложил посмотреть в сторону того, как тогда использовать этот подход на все 100%.

[nuklearlord]

Например, в нашей компании мы при обновлении API на 2ю версию, сразу завезли туда gRPC

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

[klim0v]

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

[nuklearlord]

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

[klim0v]

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

[igor_alt]

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

[klim0v]

На сегодняшний день, нет