Comments 13
Вы не Гугл. Вам не нужен grpc.
Экономия от бинарного и довольно сложного внутри протокола в обмен на усложнение всего в вашем проекте не окупится на ваших объемах. HTTP, json, gzip достаточно оптимальны и просты для вашего проекта.
Как нормально сделать аутентификацию на вашем языке и вашем фрейворке можно прочитать в любой инструкции для новичков. Это давно решенная проблема. И это решение достаточно хорошо для вашего проекта.
Согласны, мы не Гугл, поэтому, используем их решение и не разрабатываем свое. Статья обращает внимание на следующие аспекты:
ограничения стандартного REST, которые снимает gRPC
возможность организовать стриминг больших данных
возможность асинхронной передачи данных
упрощение передачи информации о потребителе сервиса (пользователь/система)
в сети встречаются горячие споры по этой теме и в настоящее время все чаще звучит заявление, что gRPC де-факто стало стандартом для межсервисного взаимодействия.
У стандартного rest нет важных ограничений. Если его использовать хотя бы более-менее разумно.
Вы не умеете стримить данные по http? Это совсем несложно.
Асинхронных http клиентов и серверов для всех массовых языков валом. Можно выбирать по вкусу.
Один-два заголовка. Это совсем несложно.
в сети встречаются горячие споры по этой теме и в настоящее время все чаще звучит заявление, что gRPC де-факто стало стандартом для межсервисного взаимодействия
Им еще предстоит понять всю силу простых хороших технологий. У http нет ни одного принципиального недостатка для типового межсервисного взаимодействия. И есть абсолютная простота.
Grpc не имеет ни одного важного преимущества перед http и дико сложен. И самое плохое что эта сложность прорастает в ваш код. Во много разных мест вашего кода. Попробуйте grpc полностью замониторить для примера. С логами, пулами, таймаутами, статусами, ошибками и тому подобное. Чтобы эти логи имели смысл и хорошо мапились на запросы и клиентов. Все как полагается. От сложности grpc нельзя абстрагироваться в отличии от сложности https, например.
У меня есть и такие и такие сервисы. http лучше прям со всех сторон, пока нет по настоящему большой нагрузки. Гигабиты на ваш сервис это хорошая грань где стоит подумать. Там усложнение уже может окупиться.
Судя по вашим высказываниям, вы не особо разбираетесь в предметной части.
grpc - это фремворк, который отличается от rest фреймворков, только тем, что данные серелизуются не в текст, а в бинарное представление.
в качестве формата данных grpc использует protobuf - бинарный формат данных. grpc работает по протоколу http2/3.
grpc также способен использовать любой другой формат данных, в том числе и текстовый.
rest - это архитектурный стиль, есть огромное множество фреймворков, реализующих его в том или ином виде. в качестве формата данных зачастую используют json, но возможны и иные форматы, например, xml, text, yaml а также protobuf.
подавляющее число реализаций работают по протоколу http1. никакого запрета или ограничения работать по протоколу http2/3 также нет.
так вот. grpc - это лишь фреймворк удаленного вызова процедур, который за последнее время стал крайне популярен, т.к. реализует простой описательный формат и предоставляет совместимые межплатформенные реализации, в отличии, например, от wcf\soap.
Мы все вроде как пишем код? И любим использовать типовые библиотечки для типовых действий. Я пишу про практическую реализацию клиент-серверного взаимодействия на основе типовых библиотечек и типовых решений. HTTP vs gRPC.
Фреймворк это хорошее слово. Под ним каждый может подразумевать что ему угодно.
Посмотрите в вашем фреймворке как реализован grpc. Прямо код прочитайте. Какие нужны усилия чтобы его замониторить и залогировать полностью? Прям каждый сантиметр чтобы по вашим мониторингам и логам было понятно вообще все что происходит. Настройте поверх балансировку и типовой https (или что угодно другое поддерживающее типовые сертификаты с LE) на вашем любимом балансировщике. Потом подебажьте парочку факапов. Заодно качество логов и мониторингов понятно будет. Там есть интересные корнер кейсы.
И наконец сравните затраченные усилия с усилиями необходимыми чтобы сделать тоже самое для HTTP.
Обычно после этого приходит понимание как прост и хорош HTTP. Когда примерно все работает из коробки. И все понятно прям сразу. При почти любом факапе.
Советую автору обратить внимание на https://github.com/LogNet/grpc-spring-boot-starter, полностью интегрирован с Spring security.
Спасибо, все передано)
Интересна либа, но мы использовали другую удобную либу io.grpc:grpc-netty:1.43.2 Статья не про это.
Какое отношение grpc-netty имеет к security? Вам самим научиться пользоваться библиотеками а не статьи поучительные писать.
Спасибо за совет. Хотим обратить внимание, что основная идея статьи — упрощение передачи данных о потребителе сервиса (пользователь/система). Такое упрощение не редкость на проектах, что хорошо дополняет и упрощает взаимодействие по gRPC и не запрещает использование стандартных механизмов из коробки.
Этот стартер https://github.com/LogNet/grpc-spring-boot-starter упрощает интеграцию с grpc - дальше некуда. Нет бойлерплейт кода, даже генерации из proto файлов автоматическая. Перечитайте документацию ещё раз
gRPC — безопасность или жесть?