Комментарии 16
А можете про плюсы/минусы grpc написать?
0
Да, напишу
0
Плюсы
Минусы
- В 2 раза компактнее JSON;
- В 3 раза компактнее XML;
- Не читается по сети
- Меньше требует CPU и памяти на десериализацию
- Доступно для всех языков
- “Умная” обратная совместимость
Минусы
- Низкая скорость по http;
- Нет гибкого описания OpenAPI.
0
Раскройте мысль, что значит «Низкая скорость по http»?
0
Если бы вы использовали нативные типы, то было бы компактнее ещё раза в 3-4.
Передавать текст по grpc, конечно, интересно. Но само по себе большого смысла не имеет.
Http вообще не имеет к grpc отношения. Это технология http2. Попытки передать grpc по устаревшим протоколам приносят результат, но не стоит от них ждать прорывной производительности.
Передавать текст по grpc, конечно, интересно. Но само по себе большого смысла не имеет.
Http вообще не имеет к grpc отношения. Это технология http2. Попытки передать grpc по устаревшим протоколам приносят результат, но не стоит от них ждать прорывной производительности.
0
Скажите, вот генерится два сервера: json rest api и grpc. Можно обращаться как через gateway так и напрямую к grpc? А в каких случаях куда ходить лучше?
Кстати не на всех языках есть grpc, на Perl его нет, кроме какого то старого, давно не поддерживаемого модуля.
Кстати не на всех языках есть grpc, на Perl его нет, кроме какого то старого, давно не поддерживаемого модуля.
0
Возможно не тема для конкретно этой статьи, но: зачем этот overhead с лишним сервисом grpc-gateway, если клиенты REST API работают по HTTP 1 и по факту ресурсов будет потребляться больше? Так имеет делать смысл, если фронтенд тоже использует gRPC (есть «промышленные» примеры WebUI на нем?). А у нас вот просто «эффективные» project манагеры приняли такое решение (везде grpc-gateway) именно потому что swagger и еще пару grpc interceptor прикручены, для лога и авторизации запросов (можно ли текущему пользователю использовать тот или иной запрос или нет). А WebUI использует просто HTTP 1.
0
Например, в нашей компании мы при обновлении API на 2ю версию, сразу завезли туда gRPC и все SDK перевели, конечно же, на него. А REST остался, тк он более привычен простым пользователям, особенно не разработчикам.
А по-поводу того что у вас. Я согласен, что использовать этот подход, не имея ввиду дальнейшее внедрение и переключение всех сервисов на gRPC, это не самое разумное использование ресурсов системы.
Если нет возможности аргументировать это Вашим менеджерам, я бы тогда все же предложил посмотреть в сторону того, как тогда использовать этот подход на все 100%.
А по-поводу того что у вас. Я согласен, что использовать этот подход, не имея ввиду дальнейшее внедрение и переключение всех сервисов на gRPC, это не самое разумное использование ресурсов системы.
Если нет возможности аргументировать это Вашим менеджерам, я бы тогда все же предложил посмотреть в сторону того, как тогда использовать этот подход на все 100%.
0
Например, в нашей компании мы при обновлении API на 2ю версию, сразу завезли туда gRPC
Было бы неплохо это сразу в статье отразить. А то у меня впечатление, что наши «эффективные» project манагеры просто зацепились за фразу, что gRPC — это круто, и пошло-поехало…
0
Генератор потдеживает 3 версию swagger aka openapi?
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Полный набор gRPC, RESTful JSON API, WS и Swagger из одного proto файла. От введения до нюансов и тонкостей grpc-gateway