Комментарии 5
Прежде всего хочется спросить, почему вы не добавили статью в хаб Java, мне кажется, она в первую очередь ценна именно для джава разработчиков.
А ещё есть вопросы по содержимому статьи. Вы описываете проблему следующим образом.
в новые сервисы транзитивно попадают зависимости, несовместимые с имеющейся версией Spring.
Я так понял, что новый подход выбран как раз для того, чтобы такого не было, но ведь модуль order-open-feign-client тянет за собой спринг точно так же, как и order-open-client. Или я что-то не так понимаю?
Я пару раз прочитал статью и у меня создалось впечатление, что транзитивные зависимости создавали вам проблемы потому что сервисам, использующим ваш клиент, нужно было обновлять версии спринга синхронно с order-api. А перевести сервис на новую версию Спринга это может быть небыстро.
И тогда вы решили, что поддерживать две версии клиента будет дешевле, чем в авральном порядке переводить сервис на новый Спринг. Я правильно понял? Или всё-таки новые версии клиентов каким-то образом и правда не тащат за собой транзитивные зависимости?
В хабы добавили. Спасибо за замечание.
Все верно, это разделение преследует 3 цели:
Транзитивно получить совместимые зависимости в месте использования
Не менять код в месте использования
Поддерживать несколько версий клиентов одновременно
Конечно, если мы будем переходить на какой-либо другой клиент, то нужно будет делать еще одну имплиментацию, следовательно появится еще один модуль с автостартером.
Полностью ли я ответил на Ваш вопрос?
Полностью ли я ответил на Ваш вопрос?
Да, вполне, спасибо )). Хотя ещё любопытно, что у вас в стартерах. Теоретически каждому клиенту может понадобиться своя конфигурация и свой собственный, например, ObjectMapper. Вы как-то делаете отдельные конфигурации для каждого клиента?
Если грубо, то как в коде на гитхабе, но фактически мы используем и@ConditionalOn...+ spring-configuratoin-metada.json, но опять таки не всегда.
ObjectMapper-ы у нас настроены однотипно, но в случае необходимости пойдем путём квалифайреов. Пока не приходилось конечно на такое идти, но примерно решение есть.
Очень больная проблема - Swagger/OpenApi, пока адекватного пути не нашли.... ну разве что убрать все аннотации из DTO и да, это не феншуйно, такой трейд-офф.
Другая проблема с ResponseEntity, но таких кейсов не много, потому изменения минимальны.
раз вы заговорили об IT-ипотеке, то откуда такое странное ограничение по возрасту 45 лет, или архитекторы и синьоры с опытом не способны погасить ипотеку?
Как мы перевели API-модули микросервисного проекта с Feign на OpenFeign