я то думал, что мы рассмотрим брокеры сообщений тоже тут. Блин... Спасибо конечно(

Маленький нюанс. Я понимаю, чтьо это люди сами могут догадаться сделать, но все же правильнее было бы показать, что вы запускаете оба сервиса, а не только gateway. К сожалению, gateway не видит payment у меня. Все перепроверил, выдает java.lang.IllegalStateException: Connection pool shut down. Одна ошибка и при запущенном и при выключенном сервисе payment. Сам payment через сваггер работает. Наверное дело в новых библиотеках, которые я использую, но не пойму - в какирх именно. Так, я использую Спринг Бут 3, соответственно - springdoc-openapi-starter-webmvc-ui вместо Спринг фокс, и apache httpclient5 .

молодец

в общем хорошо. Если не делать копипаст, а переписывать строку за строкой код, то лучше ориентируешься и понимаешь что к чему. Конечно каждый "урок" тогда превращается в полдня. Я еще и тестирование почти не трогал, поэтому заодно тестировать тренируюсь. А вообще пока мне тестирование представляется чем то излишним, каким то "маркетинговым" продуктом.Оно упрощает поиск ошибки ( не намного, Спринговый трэйс итак довольно хорошо локализует ошибку), но при этом надо кода писать в полтора-два раза больше. Я понимаю, что взгляд дилетанта, исходя из довольно скудной практики. конечно, наверное, в командной разработке без тестов не обойтись

Какая ты умничка! Большое спасибо за видосы, очень информативно и доходчиво!)))

Почему у меня pitest проверяет только контроллер? Никак не могу разобраться

Почему нету новых видео??

В целом, пока всем доволен по объяснениям. По сути, в голове складывается паззл по тому, как работают микросервисы. Было бы очень классно, после этой серии роликов увидеть серию роликов с более "боевыми" условиями, с использованием api gateway, service discovery и spring security с настройками аутентификации + jwt

Очень круто! Спасибо за информацию)

спасибо, полезно

спасибо

Почему REST API будет медленнее брокеров? В первом случае нам отвечают тут же или мы падаем по таймауту, а в другом случае нужно дождаться, когда очередь разгребут

Классно! Большое спасибо...

Оч круто🎉🎉

Полезная инфа с первой минуты

это очень хороший материал, такого (материала) не хватает

Спасибо вам, помогли ответить на большинство вопросов!

Хотелось бы с вашей подачи посмотреть уроки про докер кафку ребит.

Прекрасное объяснение!

Вау! Вот это уровень! После просмотра ролика мой телефон вышел покурить)

Так CQRS - это по сути кэш?

интересно, гно жесмтко ли я копнул, требуетсмя понять, что такое и как проводить оркестрированием данных на уровне потребителя. Это оно?)

Посмотрел весь плейлист. Супер информация ! Хотелось бы продолжения.

Очень приятный голос (вы точно не индус) и очень классное объяснение) спасибо!

Всё бы хорошо, но качество звука... Звонкий и с эхом, будто бы просто с ноутбука в пустой комнате записывали. Для подачи хорошего материала однозначно нужен хороший микрофон, хотя бы петличка для интервью, но никак не удалённые микрофоны в ноутбуках и вебкамерах!

Всё классно пока не разарвётся соединение с брокером сообщений. К сожелению в реальности схема будет немного сложнее.

9:35 Ай-ай-ай! 😁 Программистка кладёт на транзакции в прямом эфире! А если серьёзно, то, я думаю, что проблема распределённых транзакций полноценно решается только в монолите. Либо нужно правильно разделить приложение, чтобы транзакции не было распределёнными, а согласованность между сервисами устраивала бы отложенная, по событию. Но это сложно. Другой причиной, порождающей кучу проблем и в том числе сильную связанность, является использование команд. Команда - это всегда прямая связь, потому что она всегда имеет направление. Тот, кто отдаёт команду, должен знать того, кому он её отдаёт. А вот в случае использования только событий, такой проблемы нет, сервисы вообще друг о друге не знают, и согласованность организовать проще - через последовательность событий, которые хранятся в брокере.

Супер понятно!

Какая умная девушка! Вы очень понятно объясняете! Жаль, что не выходит новых видео. Недеюсь, у вас всё хорошо.

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

Джавистка - БРАВО! Отличная подача, продолжайте и не останавливайтесь.

Актуальный курс?

Очень недооцененное полезное видео. Пишу для его продвижения)

Идеально Прошерстил все возможные видео на ютубе и только здесь есть системный и методичный подход, благодаря которому хотя бы общая картина в голове выстраивается. Особенно спасибо за практические примеры.

огонь

От микросервисов до cqrs)

Спасибо Вам за Ваш труд и пояснение информации, надеюсь будут еще ролики по данной тематике

Отличный контент, спасибо за подробный разбор!

Это очень хороший контент ! Спасибо большое.

Кажется, что не правильно api gateway раскрыт, он должен быть максимально простым, а тут на этому уровне предлагают логику накручивать

а на фоне тик так тик так, что напоминает нам: время остаётся с каждой секундой меньше на секунду гениальное видео

А REST сделать асинхронно никак нельзя? Например через await HTTP Client GetAsync or PostAsync

Я так понимаю это называется хореография и оркестрация?

Отличное объяснение, спасибо за труд.

Прекрасный урок, спасибо

вопрос: а когда лучше делать синхронное взаимодействие? А то сложилось впечатление, что оно ужасно и никогда

а что значит циклическая зависимость между сервисами? Имеется в виду, что при выполнении какой-то команды, один сервис обязательно затрагивает другие?

очередь? точно очередь? может быть журнал?

Чтобы увидеть весь контент отправьте смс на короткий номер...

так а есть видео, чтоб посмотреть на практике?