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

Как собрать данные для модуля отчётности или UI?
В микросервисной архитектуре данные одного процесса размазаны по нескольким сервисам, при этом могут храниться в разных хранилищах (SQL, NoSQL, ...)

В этом видео рассказывается как можно собрать данные, не перестраивая бизнес сервисы.

Рассмотрены подходы:

1. Объединение API
2. CQRS-представления (витрины)

Рассмотрены способы использования подходов и недостатки каждого из подходов.

* Что почитать

Книга
Крис Ричардсон "Микросервисы. Паттерны разработки и рефакторинга", главы 6-7

[offmpyb]

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

[levdubrov]

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

[uknow]

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

[mr.robespierre]

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

[VkusnyashkaMMM]

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

[GalievDens]

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

[tjgtvgo]

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

[pcphymw]

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

[aggretsuko]

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

[ddcqjxg]

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

[mclotos]

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

[protiv_bio]

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

[jlcsgur]

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

[andreikashin]

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

[bugbkfz]

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

[LAV]

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

[vladzh]

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

[AK-bcls]

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