Комментарии 16
Protoc любит генерить довольно убогий код, особенно, для питона. Интересно, а если попробовать протащить обычный REST через HTTP/2?
При переходе на grpc надо очень крепко подумать. Далеко не всё там гладко, взять хотя бы отсутствие поддержки DateTime. Придётся писать кучу конвертеров. Очень много трудозатрат на поддержку актуального состояния.
Скорее всего подойдёт если вы сами предоставляете внешнее апи и отдаете nuget с прото, тогда интегрироваться с вами будет одно удовольствие. Но если вы хотите у себя сделать взаимодействие между микросервисами посредством grpc, то лучше не надо.
Поддержку предыдущего оратора. Очевидно, что gRPC будет передавать сильно меньший лбъем данных, и сериализация там эффективная, throughput вырастет. НО плата за это велика — все начнут зависеть от протофайлов, клиенты надо будет пересобирать и дистрибьютить для юинарной совместимости, для сервисов на gRPC все равно потребуется JSON front server, который будет отдавать апишку во внешний мир. protobuf очень слабый язык данных, структурно он не соответствует тому же JSON и вам надо будет костылить много конвертация.
Это не сравнить с JSON сервисом, который можно просто прокинуть наружу, и помтучаться к нему можно накидав JSON'ку в консоли.
Кстати, JSON можно зиповать на лету, это быстро, дешево и он хорошо сжимается
С таким подходом ваш API превратится в неуправляемую туеву хучу.
Кроме того protobuf по определению backward compatible, если конечно вы знаете что делаете когда его редактируете. Всё скомполированные клиенты продолжат работать с сервером на новой схеме.
для сервисов на gRPC все равно потребуется JSON front server, который будет отдавать апишку во внешний мир — полный бред. Grpc protoc плагин генерирует код для всех языков.
protobuf очень слабый язык данных, структурно он не соответствует тому же JSON и вам надо будет костылить много конвертация. — зачем вы пишете ерунду?
Kubernetes, Apache Spark и многие другие используют grpc без костылей.
Если вы страдаете от фреймворка, на это есть 2 причины:
- Вы не умеете им пользоваться
- Вы выбрали фреймворк который вам не подходит.
Мне кажется в вашем случае это #1.
Про protobuf как язык описания структур данных — я волне разделяю вот это мнение, мой опыт от использования очень похожий. А так же все эти приколы в духе "так, а это у нас пустой массив или отсутствующее значение? " https://reasonablypolymorphic.com/blog/protos-are-wrong/
Я всего лишь сказал, что добавление этой технологии в стек должно быть обосновано реальными потребностями, она добавляет изрядное количество заморочек. Сам факт, что какую-то технологию используют, без контекста ни о чем особо не говорит.
Я не очень понял что вы хотели сказать про генерацию. Что фронт-сервер не нужен, можно открывать наружу gRPC а пользователям отдавать сгенеренные клиенты?
Вы же можете воспользоваться автоматическим отражением и предоставить привычный rest внешним клиентам.
Или можете написать отдельные сервисы, которые и будут трансформировать ответ под требования клиента. Например, когда с вами должны и по rest, и по soap, у кучи других форматов взаимодействовать.
Это ни разу не проблема.
Для тех кто использует Spring boot: мой grpc spring boot starter https://github.com/LogNet/grpc-spring-boot-starter.
.
Вот спасибки за статью! Как раз эта тема интересна была! Но мне более интересно было сравнить gRPC и NetMQ (порт ZeroMQ для C#). Добавил к сравнению NetMQ. Кому интересно, вот форк репозитория: https://github.com/ILepekhov/RESTvsGRPCvsNetMQ. NetMQ однозначно по производительности выигрывает, хотя, однозначно, код сложнее под него писать.
Сравниваем производительность REST и gRPC