или в каком-то сторадже понадежнее?

в оперативке пока процесс не умрет?

В сорадже

и внимание вопрос: а что мешает синкать стораджи?)

В сорадже

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

да даже если он базу поднимает под каждую копию - пофиг) сейчас скейлится практически всё

если вдруг и это будет проблемой - стораджи тоже умеют в репликацию (особенно хорошо когда большая часть нагрузки - на чтение как у тебя)

да даже если он базу поднимает под каждую копию - пофиг) сейчас скейлится практически всё

это не меняет сути - все это масштабирование происходит в пределах одного микросервиса.

я просто проблемы понять не могу)

да я вот тоже...

Ага, все понял. Я просто почему то думал, что если мы делаем для копий сервиса общий сторож/репликации, мы выносим его состояние. Но теперь я въехал кажись)

Ага, все понял. Я просто почему то думал, что если мы делаем для копий сервиса общий сторож/репликации, мы выносим его состояние. Но теперь я въехал кажись)

это все еще состояние этого микросервиса.

с микросервисами прикольнее знакомиться через actor model

но последнее может даже сложнее потому я не уверен....

в микросервисах ты вполне можешь жить на уровне - один ограниченный контекст = один микросервис. А с экторами удобнее еще и на агрегаты дробить

хотя... ладно, тут у меня еще нет хорошо сформированного мнения

вон может Maksim за экторы понакидывает

сразу после саг)

А ещё такой вопрос, раз уже обсуждаем микросервисы. Вот если использовать composition ui подход, и ui-microservice как будет правильнее, что бы отдавали отображение ? И как быть с подключаемыми файлами ? Ну, то есть до пустим есть сервис который отдаёт отображение меню категорий, он должен отдавать чисто div блок, или ещё и стили/js ?

а зачем микросервисы этим занимаются?)

А ещё такой вопрос, раз уже обсуждаем микросервисы. Вот если использовать composition ui подход, и ui-microservice как будет правильнее, что бы отдавали отображение ? И как быть с подключаемыми файлами ? Ну, то есть до пустим есть сервис который отдаёт отображение меню категорий, он должен отдавать чисто div блок, или ещё и стили/js ?

мм.... что будет если на твоем проекте если у тебя 20 микросервисов занимаются отрисовкой своего UI если вы затеяте глобальный редизайн?

как масштабировать разработчиков если у тебя есть 3-4 фронтендера и те же 20 микросервисов?

микросервисы ради микросервисов до добра не доводят

как ты будешь разруливать A/B тестирование нового UI?

как ты будешь разруливать A/B тестирование нового UI?

Тестировать чисто компоненты в отдельности

а/б тестирование как бы не про изоляцию компонентов

Тестировать чисто компоненты в отдельности

это может идти в разрез с целями

Ну, тогда по факту можно для тестирования просто перекрыть микросервис которые отрисовывают компонент, и использовать для каждой группы свои

Что зовётся микросервисом-то?

Ну, тогда по факту можно для тестирования просто перекрыть микросервис которые отрисовывают компонент, и использовать для каждой группы свои

но зачем!? если можно иметь один гейтвей который занимается отрисовкой микросервисов?)

или несколько если у тебя например есть разный UI для разных ролей

Что зовётся микросервисом-то?

В данном случае сервис который обращается к API получает данные, отрисовывает их и отдаёт отображение.

В данном случае сервис который обращается к API получает данные, отрисовывает их и отдаёт отображение.

API чье?

другого микросервиса?

Это прям так надо было выносить в отдельное приложение? Чёи нипанимать малость

API чье?

Фактически того же сервиса.

> composition ui подход

для меня вот это вот означает что у нас есть один микросервис занимающийся агрегацией данных из многих микросервисов с целью отрисовки UI

Это прям так надо было выносить в отдельное приложение? Чёи нипанимать малость

Ну, скорее для универсальности компонентов. Центральная машина просто получает уже готовые блоки

Ну, скорее для универсальности компонентов. Центральная машина просто получает уже готовые блоки

но в чем смысл? и не будет ли у тебя "похожих" блоков в разных контекстах?

для меня вот это вот означает что у нас есть один микросервис занимающийся агрегацией данных из многих микросервисов с целью отрисовки UI

По моему это монолитный ui. https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout

имхо, тут как раз случай микросервисов ради микросервисов. Профита не получили, а проблем - до жопы)

По моему это монолитный ui. https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout

представь себе что ты делаешь бэкэнд на микросервисах для мобильного приложения

у тебя тут не особо есть выбор)

да и потом - ты когда выбираешь подход - у тебя должны быть сформированы задачи которые нужно решить

а так - выглядит как реально подходы ради подходов

но в чем смысл? и не будет ли у тебя "похожих" блоков в разных контекстах?

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

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

другой пример. У тебя есть каталог товаров, новости, форум и доска объявлений. И есть поиск который сейчас у каждого свой.

ты будешь реализовывать компонент поиска у каждого микросервиса свой?

будешь заводить микросервис поиска которому нужно явно указывать контекст (на UI же надо показывать где мы ищем) или микросервис каталога будет просить микросервис поиска отрендрить ui компонент?

будешь заводить микросервис поиска которому нужно явно указывать контекст (на UI же надо показывать где мы ищем) или микросервис каталога будет просить микросервис поиска отрендрить ui компонент?

Если поиск по каталогу, то да компонент каталога будет запрашивать компонент поиска и рендерить его в себе

Если поиск по каталогу, то да компонент каталога будет запрашивать компонент поиска и рендерить его в себе

добавим к этому всякие модные ajax/react-ы

как будешь дальше жить?

добавим мобильное приложение для части функционала

и вон твоя красивая концепция того как рендрить UI уже рассыпается и приедтак так или иначе делать какой-то агрегатор

добавим к этому всякие модные ajax/react-ы

И так все с Ajax) ну когда рендерится поиск туда внедряют параметры с кем ему нужно общаться и все.

И так все с Ajax) ну когда рендерится поиск туда внедряют параметры с кем ему нужно общаться и все.

допустим мы делаем какое-то приложение и нам выгоднее это делать на react/angular/ember

+ мобильный клиент

добавим мобильное приложение для части функционала

Ну, технически мы может в моб приложении использовать webView))

Ну, технически мы может в моб приложении использовать webView))

технически - да, но мы вряд-ли так будем делать

а если и будем - внутри будет все тот же react/angular

иначе мы могли бы обойтись чисто мобильной версией

допустим мы делаем какое-то приложение и нам выгоднее это делать на react/angular/ember

Ну, это тогда совсем другой подход, и тогда проще юзать single-ui. Хотя я думаю и тут можно как то независимо его прикрутить.

мы ж мобильное приложение не просто так делаем а потому что нам помимо "показать" надо как-то упроститиь взаимодействие используя профит мобильной платформы

а если и будем - внутри будет все тот же react/angular

Ну тогда это single-Ui

Ну, это тогда совсем другой подход, и тогда проще юзать single-ui. Хотя я думаю и тут можно как то независимо его прикрутить.

давай теперь вернемся к главному вопросу

а хотя не

ERROR: S client not available

еще один маленький и вернемся к главному

Ну тогда это single-Ui

у тебя есть один бэкэнд который обслуживает 4 разных UI с частью функционала сквозного, и частью самостоятельного под каждую роль.

и главный вопрос - чем плох подход "монолитного UI" если он не такой уж и монолитный?

и главный вопрос - чем плох подход "монолитного UI" если он не такой уж и монолитный?

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

с точки зрения разделения ответстенноости - даже лучше, с точки зрения удобства эксплуатации - тоже лучше, с точки зрения связанности.... ну тут да, тут сложнее держать себя в руках и не связать этот UI со всеми микросервисами.

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

он получается кохизив, то есть все изменения имеют под собой одну и ту же причину

у тебя есть один бэкэнд который обслуживает 4 разных UI с частью функционала сквозного, и частью самостоятельного под каждую роль.

Что подразумевается "под каждую роль", и "сквозной функционал" ?

у тебя у системы как правило есть разные роли пользователей

например... если мы пилим убер - у тебя есть роль пассажира и водителя. А еще есть менеджмент.

сквозной функционал - это общий для нескольких ролей. Например история поездок будет использоваться и там и там

но с точки зрения UI будет чуть-чуть отличаться

Ну, тогда системе ведь все равно на то кто Ее использует. А доступ по сути это уже ответственность ACL. По этому микросервиссу все равно кто к нему обращаешься, главное что бы права были.

А от того что API дёргает тот или иной UI, API не знает. Или я не дополнял проблему ?

Ну, тогда системе ведь все равно на то кто Ее использует. А доступ по сути это уже ответственность ACL. По этому микросервиссу все равно кто к нему обращаешься, главное что бы права были.

системе - все равно, а вот пользователям - не все равно. Они являются источником изменений требований. А это означает то, что мы будем менять под них

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

Но под них мы будем менять UI, либо добавлять API, го это по идее тоже не связанные процессы

именно не связанные. API ты будешь менять если захочешь чуточку поведение поменять. И часто это изменение в поведении сопровождается изменениями на UI

но с UI эксперементировать нам надо больше (а точнее с UX)

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

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

НО! есть свои минусы - в частности связанность

так что более менее адекватный вариант будет находиться где-то по середине между "один микросервис для всего UI" и "каждый микросервис готовит для себя UI". Последнее с точки зрения связанности даже больше проблем будет иметь

ну либо надо научиться трансклудам/декорации компонентов

Но вот в случае когда есть сервис который отдаёт UI компонента, нам проще экспериментировать. Мы выкатили ещё один сервис. Все скрыли его за прокси и отдаём теперь то тот то тот. И больше никто не знает что что то поменялось. Мы по сути добавили в систему новый компонент, не нарушив старую связь.

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

Но вот в случае когда есть сервис который отдаёт UI компонента, нам проще экспериментировать. Мы выкатили ещё один сервис. Все скрыли его за прокси и отдаём теперь то тот то тот. И больше никто не знает что что то поменялось. Мы по сути добавили в систему новый компонент, не нарушив старую связь.

проблемы начинаются тогда, когда вдруг окажется что с точки зрения UI разделение на компоненты отличается от "с точки зрения бизнес логики"

Когда один UI говорит с нескольким API ? Или я недопонял

да, например, к какому микросервису ты отнесешь этот UI

Ну, это может быть отдельный агрегатный UI работающий с несколькими сервисами.

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

предположим я захожу на страничку твоей системы. И у нас как раз та ситуация что UI кусочка страницы нужно агрегировать с разных сервисов

кто меня встретит первым? и кто заберет компонент из нашего UI-сервиса?