:)

Кайф!

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

Да ну куча проблем у gRPC-web. Вот приходит вам мессаг-респонс, и нужно её прочитать. Вы делаете toObject и если в глубине есть тип google_protobuf_struct_pb.Struct то оно превратится в fieldsMap. И можно конечно на Struct юзать toJavaScript, но Struct может быть очень глубоким потомком jspb.Message и во-первы, идти через геттеры к нему крайне неудобно, а во-вторых, нам нужно все дерево и нужно как-то мержить результат toObject и его потомка. С типизацией у Struct тоже плохо - она вообще не имеет типа и это реально приводит к проблемам в typescript. В целом ну очень неудобно, имхо.

Я бы посмотрел как ты свагером нагенеришь код под бинарные сообщения

Я мешаю

@@kalashnikofsergey7064 чем? Тут ведь речь шла не об удобстве и трудозатратах, а о принципиальной возможности.

это помимо того, что json, как и любой текст, прекрасно жмётся апаратными средствами, прозрачно для разработчика.

даже сжатый JSON все равно занимает больше места, чем protobuf - nilsmagnus.github.io/post/proto-json-sizes/

@@alishevN Честно не много не понял,так если проблема в размере JSON,что мешает весь JSON прогнать через protobuf и отправить? я ничего не имею против gRpc но в большом проекте где под 1000+ методов которые взаимодействуют с различными микросервисами замучаешься всё описывать в .proto (для такой задачи надо нанимать отдельно человека на должность mapper ;) )

@@FastDamage у нас в C# можно описывать интерфейсы)

Автор даёт ссылку на тесты. Там видно что при коротких сообщениях прото дает выигрыш. Однако на больших сообщениях явно теряет преимущество. Я думаю что нужно ещё больше тестов. Повысить энтропию данных, зажать их и посмотреть что получиться. Есть шанс что в разных ситуациях, в разных задачах придется выбирать между прото или json вариантом, так как есть зависимость от объема данных и рассеивании. Аргумент того что json сжатие требует процессорное время, такое себя, так как любое сжатие этого требует. Нужно больше хороших синтетических тестов и тестов из жизни, реальных проектов. Но по мне, пока что, JSON выглядит лучше, даже если на коротких сообщениях проигрывает.

не парься, ещё долго рест будет актуален.

так же делаю

по спрингу я записываю полный курс. выйдет через месяц-два

EJB аналогичен по своей сути мультимодульному проекту на мавене, когда монолит делят на разные куски в зависимости от его действий в приложении, например, один ejb компонент отвечает за DAO, другой бизнес логика, другой интеграция с внешними сервисами и ТД. Концепция миеросесервисов строится вокруг DDD подхода в рамках которого у каждого сервиса может быть и свой dao слой, и свой слой интеграции и своя бизнес логика. А по поводу RMI, так эта технология и так используется в спринг клауд и является его базой. Grpc в отличии от RMI можно сипмлементировать на любом языке, таким образом не завязываясь на определенном стеке, в то время как клауд в рамках одного цельного приложения это набор микросервисов на java

да, правильное замечание, но даже сжатый JSON все равно занимает больше места, чем protobuf - nilsmagnus.github.io/post/proto-json-sizes/

@@alishevN При передаче данных по каналам связи, что текст, что бинарные файлы сжимаются. Текст лучше, бинарные данные меньше, а в целом получающийся пакет примерно одинаков, разница в 5-10%. Излишний размер влияет на надежность, текстовый формат передается чуть медленнее, но надежнее. Все вышеописанное влияет на передачу между удаленными серверами, в случае связи между близкорасположенными серверами, без использования внешних каналов, т.е. интранет, то тут бинарный формат в 7-10 раз может быть быстрее.

GraphQL вам в помощь.

Из предложений по улучшению контента: можешь приобрести планшет или ноутбук с поддержкой стилуса (ручки) для интерактивного добавления материала поверх слайдов.

@@ramilsafin5751 Спасибо за фидбэк!) Подумаю над этим.

Думаю тут скорее для лучшего понимания используется именно такой подход декларации переменных.

Если не нравится делай на старых технологиях, и как ты собираешься организовывать стримы?

Все верно, нужно создавать отдельный гит-проект (если используется гит) и туда класть прото-файлы. В микросервисах затем подключать этот проект с помощью подмодулей (submodule) (используем в ежедневной работе), либо subtree (это не пробовал).