Микросервисы. Проектирование API

[@mr.robespierre]

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

[@levdubrov9522]

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

[@uknow2908]

Спасибо за видос! Очень интересно. Что-то новое для себя почерпнул, что редко, потому что про микросервисы обычно говорят одно и то же. А тут прям новое и с хорошей подачей.

[@Джавистка]

Спасибо, очень приятно))

[@РобертСабиров-и8л]

Хороший контент, не ожидал от такого небольшого канала. Сразу же подписываюсь и буду ожидать новых видео. Спасибо за материал!

[@VkusnyashkaMMM]

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

[@Goga_Furt]

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

[@ЮрийЗапольский]

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

[@КириллСеманченков-ф9в]

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

[@GalievDen1s]

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

[@ivankarash2646]

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

[@aggretsuko6794]

да, спасибо. первое о чем я подумал после твоего вопроса (3:31) это создание промежуточного сервиса, где данные будут обрабатываться и передаваться клиенту в нужном виде.

[@Джавистка]

микросервисы дают большое поле для идей и различных реализаций. Ну и как следствие, предоставляют много возможностей "выстрелить себе в ногу". Поэтому нет одного правильного ответа на вопрос "как делать", в каждой ситуации нужно анализировать, что лучше подходит, при этом учитывая требования к нагрузке и быстроте выполнения. Я к тому, что можно пробовать другие решения, и эти другие решения тоже могут быть рабочими

[@AndreiGrishin-j4r]

Отличное практико-ориентированное объяснение!

[@achutagradjadasabvg5269]

молодец

[@nielsbohr7322]

очень хорошая подача материала!

[@alex331911]

Супер материал! Ждем продолжения!

[@АлексейКузьмичёв-ц7о]

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

[@javastream9414]

Спасибо, очень помогло.

[@geghamkocharyan9172]

Класс 👍

[@arenmkhoyan]

Оч круто🎉🎉

[@mclotos]

есть такая штука как graphQL, которой можно слать запросы, формировать ответы и т.д., у graphql есть такая штука как graph subscribe, которая может уведомлять подписчика о том, что в каком-то сервисе изменились данные. нафига еще какая-то прослойка, которая, о ужас, тоже может уйти в отказ, если есть брокер сообщений (например rabbitmq), который внезапно умеет уведомлять клиента о том, что данные изменились или запрос обработался - оформил подписку и жди сообщения. В итоге имеем rabbit, у которого поднята куча каналов; микросервисы, которые читают/пишут в эти каналы; клиент, который слушает эти события и все они общаются через graphql.

[@Deletedeletedelete]

А что по кешированию и n+1 у graphql?

[@mclotos]

@@Deletedeletedelete ну кеширование есть и на серверной стороне и на клиентской, а по n+1 нуу как бы так же как и с rest -- криворукость будет заметна не сразу. Но я об этом не парюсь -- у меня кролик есть и в случае, если какой-то сервис зависнет, то вместо него поднимается новый, а может даже несколько и они какое-то время будут работать вместе, пока нагрузка не упадёт, а потом резервные сервисы опять уйдут в спячку. Можно и без кролика, например через Apollo Gateway, но там не знаю как он балансирует нагрузку и распределяет запросы по сервисам, у меня на кролике дикая маршрутизация настроена

[@VitaliyParhomenko-w5b]

Спасибо

[@protiv_bio]

Расскажите пожалуйста о разнице микросервисной архитектуры и акторной модели

[@Jekklo]

класс. Просто ащще огонь.

[@nexsmith8276]

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

[@mqtrade5743]

Пару слов для продвижения ролика

[@andreikashin]

нету никаких "коммандных запросов". есть комманды (запись) и запросы (чтение) - вот их и разделяют [CQRS]

[@LAV451]

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

[@Ник-ц7х]

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

[@AK-bc4ls]

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

[@vladzh2639]

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

[@МаксимДругой-з1н]

Тема брокера сообщений не раскрыта. Почему его ввели? Почему он есть во 2 и 3 примерах и нет в 1?

[@Джавистка]

Не удалось объяснить чем отличается подход 1 от подхода 2? Предполагается, что в системе есть брокер. В видео рассказывается, как можно собрать данные в одном месте: в одном случае используется информация, передаваемая через брокера; в другом - идëт обращение к самим сервисам. Если я не ошибаюсь, о надобности брокера в микросервисах рассказывается в более ранних видео, возможно даже в первом видео про микросервисы