Comments 8
Почему не взять grpc? Автогенерация для большинства популярных языков и фреймворков. Чем ваш подход лучше?
Я не говорю, что мой подход лучше grpc или это его замена.
У моего инструмента есть область применения.
Какие вводные:
- У вас один язык программирования - java.
- У вас один продукт\проект ограниченной зоны деплоя - один сервер, один namespace k8s/openshift.
- Этот инструмент применяется только внутри вашего проекта, не выставляя API на внешнего потребителя.
- Команда\команды в среднем не работали с grpc (критически важный пункт, когда продукт находится в активной стадии).
Удобство относительно grpc в этом случае будет, что для выставления API достаточно будет описать java интерфейс с набором DTO. А это быстрее, чем описать protobuf файл с сложной иерархией объектов.
Так же достаточно легко будет замокать интерфейс при юнит тестировании.
На самом деле описать схему протобаф по dto модели это 5 минут пользуясь тем же чатгпт или дипсик. Опять же в случае с grpc вы получаете проверенный оттестированый транспорт, асинхронный клиент из коробки. Не понимаю правда зачем в 2025 городить свой rpc.
Ещё вопрос, а тестировать как руками? С рестом понятно, для grpc сейчас тоже есть клиенты. Будете ещё тулинг писать к своему протоколу?
А если нужна балансировка нагрузки к примеру, несколько экземпляров одного сервиса, авторизация. Нужно до-придумывать логику.
Есть же OpenFeign. Кажется он как раз и решает подобную проблему.
Отвечу на вопросы по частям.
OpenFeign это инструмент для REST API. Он не является классическим rpc инструментом, хоть и может использоваться в rpc стиле. В использовании же он многословен, я имею ввиду, что интерфейс, который описываем, нагружен кучкой аннотаций (что, конечно, не является проблемой).
Заметным отличием от того, что я показал в статье будет работа с исключениями. OpenFeign будет оперировать http кодами ошибок и того что пришло в теле (для более сложных случаем придется описывать ErrorDecoder).
В моем же примере, вы можете выкинуть исключение на серверной строне throw new ClientNotFoud("..."), а на клиенте обработать через обычный try-catch-finally.
Балансировка нагрузки не часть ответственности инструмента. Балансировать можно средствами nginx или, если вы на k8s/openshift, то средствами istio.
Авторизация так же за границей инструмента.
Попробуйте запустить пример на github.
А если на стороне клиента нет класса этого исключения?
В копилку к Feign добавлю нынешние Declarative HTTP Client-ы спринга встроенные.
Точно ли изучение вместо gRPC более лёгкого, но местечкового, инструмента даст коллегам возможность расти в отрасли, они же не до конца жизни на этом проекте? (это просто наброс на то, что достаточно ли это взвешенное решение, или принято под давлением нехватки компетенций).
А если на стороне клиента нет класса этого исключения?
Исключение должно идти в рамках контрактах, т.е. в API пакете. На моей практике, все такие случае были отловлены на этапе интеграционного тестирования на стенде тестирования.
Точно ли изучение вместо gRPC более лёгкого, но местечкового, инструмента даст коллегам возможность расти в отрасли, они же не до конца жизни на этом проекте? (это просто наброс на то, что достаточно ли это взвешенное решение, или принято под давлением нехватки компетенций).
Я буду делать отсылку на проект, в котором подобный тип инструмента встретил.
К проекту я присоединился в 2020 году, год, когда начали активно импортозамещать продукт написанного на основе oracle siebel. В моей команде, не было никого кто знал бы java, при этом эти ребята были крутейшими профессионалами в предыдущем стеке.
Так же со стороны руководства было требование использование wildfly в качестве сервера приложений (шок в шоке в 2020) и rpc инструмента для взаимодействия между приложениями.
В такой ситуации добавление grpc бессмысленна.
В последующем перевели проект на openshift и сбросили все легаси, а вот rpc инструмент для внутренней коммуникации хорошо прижился (т.е. в рамках namespace openshift). При этом некоторые внешние API уже, конечно, используют grpc.
Исключение должно идти в рамках контрактах, т.е. в API пакете. На моей практике, все такие случае были отловлены на этапе интеграционного тестирования на стенде тестирования.
Хорошо, если все, но теоретически ведь может какой-то неожиданный RuntimeException проскочить, или даже ... Error. Надеюсь, на клиентской стороне эта ситуация как-то обработается, а не бросит ClassNotFoundException.
В такой ситуации добавление grpc бессмысленна.
В такой, скорее, соглашусь. Если прижилось, значит удобно. Но очень часто бывает, когда пытаешься прикрутить что-то удобное самодельное в одном месте в другое место, возникают новые краевые кейсы, и оказывается, что решение ещё не дожато :)
Реализация RPC во внутреннем взаимодействии модулей с Spring Boot