Советы и уловки

Причины выбрать gRPC вместо REST и как внедрить его в свои API Python

Когда gRPC может стать альтернативой REST для передачи сообщений?

Уже давно у нас есть REST (REpresentational State Transfer). REST API удобны, теплы, дружелюбны и очень гибки. И если мне позволено быть здесь немного резким, слава богу, мне больше не нужно использовать SOAP!

Так почему, черт возьми, мы снова хотим все изменить? Почему мы продолжаем изобретать новые блестящие вещи, чтобы заменить инструменты, которые так хорошо работают? Что это за gRPC сейчас?

Что ж, простой ответ: «не существует одного размера, который подошел бы всем». Если бы вы доставили письмо как можно быстрее и надежнее, как бы вы это сделали? Первая мысль, которая приходит мне в голову, - это то, что я сделаю это сам. Садись в мою машину, поеду к месту назначения и позвони в звонок собственными пальцами.

Но, может быть, у меня нет времени на это самому. Так что я бы, наверное, позвонил в Uber и воспользовался соответствующей услугой. Подожди сейчас; это становится слишком дорого. Кроме того, что, если пункт назначения находится на другом конце света? Экспресс-почта - лучший вариант. Различные решения одной и той же проблемы.

В любом случае знание многих преимуществ и недостатков использования одной формы метода передачи сообщений по сравнению с другой имеет решающее значение при разработке коммуникационных API-интерфейсов между микросервисами. В этой истории мы увидим, когда выбрать gRPC вместо REST и реализовать службу gRPC на Python.

Learning Rate - это информационный бюллетень для тех, кто интересуется миром AI и MLOps. Каждую пятницу вы будете получать от меня обновления и мысли о последних новостях и статьях об искусственном интеллекте. Подпишитесь здесь!

Что такое ОТДЫХ?

Как мы уже видели, REST расшифровывается как «REpresentational State Transfer». Он предоставляет набор рекомендаций по созданию веб-API. Но это все, набор рекомендаций. Он не пытается ничего принудить.

Если вернуться к нашей аналогии с доставкой почты, есть несколько рекомендаций по написанию письма. Вы можете начать с даты, информации и адреса получателя, а затем приветствовать. В конце вы можете закрыть письмо своей личной подписью.

Однако есть ли кто-то или что-то, чтобы обеспечить соблюдение этих правил? Будет ли почтальон отказать в доставке письма, не соответствующего этим правилам? Нет! Вы даже можете нарисовать картинку внутри, если хотите. В конце концов, говорят, что картинка стоит тысячи слов.

Так каковы же свойства REST?

  1. Клиент-сервер: клиент делает запрос и получает ответ от сервера. Клиенту не нужно знать, как реализован сервер. Ему также не нужно знать, отправляет ли сервер обратно кэшированные ответы или его запрос прошел сто уровней до получения ответа.
  2. Отсутствие состояния: каждый запрос является автономным и включает всю информацию, необходимую для его обработки. Сервер не отслеживает какой-либо контекст.
  3. Единый интерфейс: интерфейс API должен быть согласованным, документировать формат сообщения, конечные точки и заголовки сообщений.

Разработка REST API на Python действительно проста, но выходит за рамки этой истории. Если вы хотите увидеть, как это делается, обратитесь к документации Python Flask.

А как насчет gRPC?

gRPC - это метод передачи сообщений, разработанный Google. Но «g» в gRPC не означает «google»; на самом деле это довольно случайно. Например, буква «g» в gRPC 1.12 означает «великолепно».

gRPC не зависит от языка программирования, и, похоже, это новая тенденция в мире коммуникации микросервисов. По сравнению с REST, gRPC обеспечивает большую производительность за счет меньшей гибкости.

Итак, gRPC не предоставляет набор руководящих принципов по созданию веб-API; он обеспечивает соблюдение правил. На этот раз почтальон очень разозлится, если вы не начнете письмо с должного приветствия!

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

gRPC и Python

Теперь давайте создадим сервер gRPC на Python. Первый шаг, который мы должны сделать, - это определить структуру нашего сообщения как protobuf файл. В этом примере мы предполагаем, что мы книжный магазин, и мы хотели бы получить книги, которые есть в нашем каталоге, и добавить новые.

Этот файл (т. Е. book.proto) определяет новое сообщение BookMessage, которое должно содержать код ISBN, заголовок, автора, описание, цену и условие и в указанном порядке.

Затем он определяет новую службу (т.е. BookService), которая может создать новую книгу или получить все существующие.

Далее, реализация gRPC с Python включает две библиотеки:

  • grpcio для запуска клиентского и серверного кода
  • grpcio-tools для генерации кода определения

Вы можете установить их оба с помощью следующей команды:

pip install grpcio grpcio-tools

После установки этих библиотек используйте grpcio-tools одну для создания кода, необходимого для создания сервера и клиента gRPC. Выполните следующую команду:

python -m grpc_tools.protoc -I./ --python_out=./ --grpc_python_out=./ book.proto

Эта команда должна создать два файла:

  • book_pb2.py
  • book_pb2_grpc.py

Редактировать эти файлы напрямую - не лучший вариант. Если вам нужно что-то изменить, измените файл .proto и повторно запустите команду, чтобы повторно сгенерировать два файла Python.

Теперь мы можем использовать эти файлы для создания нашей службы gRPC:

Наконец, давайте создадим клиента для тестирования нашего сервиса:

Клиент создает новый объект BookMessage и отправляет его на сервер. Исходя из этого, мы предполагаем, что сервер хранит эту новую книгу в каталоге магазина.

Заключение

gRPC кажется новым классным парнем в городе, но он не заменит REST. В общем, REST получил более широкое распространение. С другой стороны, gRPC более структурирован и обычно работает быстрее.

Предположим, вам нужна скорость или структура, используйте gRPC. Итак, хорошим вариантом использования gRPC будет внутренняя связь ваших микросервисов. С другой стороны, лучше предоставить конечную точку REST внешнему миру, поскольку REST используют все.

об авторе

Меня зовут Димитрис Поулопулос, я инженер по машинному обучению, работающий в Arrikto. Я разработал и внедрил ИИ и программные решения для крупных клиентов, таких как Европейская комиссия, Евростат, МВФ, Европейский центральный банк, ОЭСР и IKEA.

Если вы хотите прочитать больше сообщений о машинном обучении, глубоком обучении, науке о данных и DataOps, подпишитесь на меня в Medium, LinkedIn или @ james2pl в Twitter.

Выраженные мнения являются исключительно моими и не отражают взгляды или мнения моего работодателя.