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

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

Спасибо за подробный перевод! Давно уже было интересно, насколько современный protobuf легок в использовании. Автор оригинальной статьи пишет, что потратил немного времени на реализацию простого сервиса, причем нужные инструменты интегрированы в VS. Немного смущает только то, что в статье речь о NET Core 3.0 идет как о самой новой версии, а вокрег уже вовсю используется следующая версия, пятерка

Так ведь оригинальная статья от 3 апреля 2019 года.

тож обратил внимание на .NET Core 3.0 который уже не поддерживается даже

Protoc любит генерить довольно убогий код, особенно, для питона. Интересно, а если попробовать протащить обычный REST через HTTP/2?

Ничего не даст.

При переходе на grpc надо очень крепко подумать. Далеко не всё там гладко, взять хотя бы отсутствие поддержки DateTime. Придётся писать кучу конвертеров. Очень много трудозатрат на поддержку актуального состояния.
Скорее всего подойдёт если вы сами предоставляете внешнее апи и отдаете nuget с прото, тогда интегрироваться с вами будет одно удовольствие. Но если вы хотите у себя сделать взаимодействие между микросервисами посредством grpc, то лучше не надо.

Поддержку предыдущего оратора. Очевидно, что gRPC будет передавать сильно меньший лбъем данных, и сериализация там эффективная, throughput вырастет. НО плата за это велика — все начнут зависеть от протофайлов, клиенты надо будет пересобирать и дистрибьютить для юинарной совместимости, для сервисов на gRPC все равно потребуется JSON front server, который будет отдавать апишку во внешний мир. protobuf очень слабый язык данных, структурно он не соответствует тому же JSON и вам надо будет костылить много конвертация.
Это не сравнить с JSON сервисом, который можно просто прокинуть наружу, и помтучаться к нему можно накидав JSON'ку в консоли.
Кстати, JSON можно зиповать на лету, это быстро, дешево и он хорошо сжимается

С таким подходом ваш API превратится в неуправляемую туеву хучу.
Кроме того protobuf по определению backward compatible, если конечно вы знаете что делаете когда его редактируете. Всё скомполированные клиенты продолжат работать с сервером на новой схеме.

Мне не очень ясно, как менеджмент API связан с протоколом сериализации? Строгую схему и контракт можно поддерживать в любом формате.

для сервисов на gRPC все равно потребуется JSON front server, который будет отдавать апишку во внешний мир — полный бред. Grpc protoc плагин генерирует код для всех языков.
protobuf очень слабый язык данных, структурно он не соответствует тому же JSON и вам надо будет костылить много конвертация. — зачем вы пишете ерунду?
Kubernetes, Apache Spark и многие другие используют grpc без костылей.
Если вы страдаете от фреймворка, на это есть 2 причины:


  1. Вы не умеете им пользоваться
  2. Вы выбрали фреймворк который вам не подходит.
    Мне кажется в вашем случае это #1.

Про protobuf как язык описания структур данных — я волне разделяю вот это мнение, мой опыт от использования очень похожий. А так же все эти приколы в духе "так, а это у нас пустой массив или отсутствующее значение? " https://reasonablypolymorphic.com/blog/protos-are-wrong/


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


Я не очень понял что вы хотели сказать про генерацию. Что фронт-сервер не нужен, можно открывать наружу gRPC а пользователям отдавать сгенеренные клиенты?

Вот спасибки за статью! Как раз эта тема интересна была! Но мне более интересно было сравнить gRPC и NetMQ (порт ZeroMQ для C#). Добавил к сравнению NetMQ. Кому интересно, вот форк репозитория: https://github.com/ILepekhov/RESTvsGRPCvsNetMQ. NetMQ однозначно по производительности выигрывает, хотя, однозначно, код сложнее под него писать.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
otus.ru
Численность
51–100 человек
Дата регистрации
Представитель
OTUS

Блог на Хабре