Что "в связях"?

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

тогда они перестанут быть независимыми, не? )

а если эти три компонента просто чекают это состояние, а не меняют?

а если эти три компонента просто чекают это состояние, а не меняют?

чекают = "зависят от", правильно?

а если эти три компонента просто чекают это состояние, а не меняют?

у тебя всеравно от них зависимости есть

прочекал, получил true, сработал if, получил false - сработал else

это ли не зависимость?

а что плохого может случиться от одной бд?

централизованной?

bottleneck

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

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

single point of failure

а что плохого может случиться от одной бд?

пролема не в БД а в зависимостях. Когда у тебя одна база данных легко случайно завязать один микросервис на данные другого и это будет неявно

и это тоже

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

пролема не в БД а в зависимостях. Когда у тебя одна база данных легко случайно завязать один микросервис на данные другого и это будет неявно

Кто же мешает микросервису начать слушать события с топика, которым он не пользуется?

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

Это твои выдумки

Это твои выдумки

ну просвяти че

Кто же мешает микросервису начать слушать события с топика, которым он не пользуется?

если он слушает значит пользуется. То что он данные никак не юзает - так и ладно. Значит если ивентов не будет то ничего не сломается

Микросервисы это решение не технических проблем, а менеджерских: дешевле иметь n групп пишущих на разных ЯП и вообще технологиях, чем одну группу с одним стеком.

если он слушает значит пользуется. То что он данные никак не юзает - так и ладно. Значит если ивентов не будет то ничего не сломается

То же самое можно сказать и о БД

Микросервисы это решение не технических проблем, а менеджерских: дешевле иметь n групп пишущих на разных ЯП и вообще технологиях, чем одну группу с одним стеком.

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

Я не за shared db, если что. Просто ты аргументирует ну совсем странно

То же самое можно сказать и о БД

вот только с БД всегда есть возможность делать нехорошие вещи, с брокерами проще

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

С чего ты решил, что одно приложение не может содержать n процессов?

Пофигу что в контейнер херачить

С чего ты решил, что одно приложение не может содержать n процессов?

может, и n процессов не делает приложение "микросервисами"

От того, что там несколько процессов, система не становится микросервисной

ну да, верно

ну то есть идея в том что бы эти "несколько команд" с разными языками и все что ты перечислил не сильно влияли друг на друга. Что бы если у одной команды что-то пошло не так, то это заафектило бы небольшую часть приложения а не все приложение

что в свою очередь позволяет чаще релизиться

а чаще релизиться = меньше изменений за раз

а это тоже уменьшает риски

вот только я на своей практике работал только с 2 проектами где микросервисы были оправданы

и делать их на старте можно только если ты на 100% уверен что оно тебе надо (а это 0.001% проектов)

потому мне больше нравится делать монолиты с изоляцией... там проще

потому мне больше нравится делать монолиты с изоляцией... там проще

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

и ты можешь каждому физически в бубен настучать если что

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

ну вот на моем проекте мы уже потиху упираемся в то что разрастаться начинаем

но тут скорее искуственно команду раздули

с ребятами составляем начальству письма что мол "мы все делаем не так, давайте по другому"

Если у меня спа приложение, то api gateway будет на джсе, так ?

what

Если у меня спа приложение, то api gateway будет на джсе, так ?

даже если не спа

или фронт не должен знать ничего

Если у меня спа приложение, то api gateway будет на джсе, так ?

если я пеку блины, то гардины надо голубые покупать?

конечно не должен, кек)

Фронт это api gateway + клиент

его переписать можно

а не только клиент

лан

харе

если я пеку блины, то гардины надо голубые покупать?

Эй нет

Клиент должен сам готовить себе данные

Клиент должен сам готовить себе данные

в смысле?)

С фильтрацией секретных данных и прочее

ну может я не так тебя понял

Потому api gateway должны пилить клиентские разрабы

А для них очевиден выбор js (ts/etc)

Потому, да, api gateway будет на жс в 99% случаях

хз, я своих фронтендеров на бэк не пускаю

Это не бэк

какой еще апи гейтвей на жсе

вы о чем

дык чо мне делать то, решите уже :D

ERROR: S client not available

с каких пор гейтвей вообще на клиенте

Это не бэк

а ты уверен что ему гейтвей нужен?)

с каких пор гейтвей вообще на клиенте

С каких пор жс только на клиенте?

с каких пор гейтвей вообще на клиенте

видимо имеется ввиду мидлвэр который оптимизирует все под клиент

а ты уверен что ему гейтвей нужен?)

Я не решаю его проблему

Был конкретный вопрос про ЯП api gateway

видимо имеется ввиду мидлвэр который оптимизирует все под клиент

Угу

С каких пор жс только на клиенте?

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

Так как писать должны его клиентские разрабы, то там будет клиентский яп, всё просто

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

но не бэк, прослойку между бэком и клиентом

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

Это не значит, то оно на клиенте

но не бэк, прослойку между бэком и клиентом

но все ж относится это к бэку по факту то?

Ну смотря какую терминологию брать

к серверу т.е.

Как минимум в яндексе и мейле фронт это именно api gateway и клиент

А не только клиент

к серверу т.е.

с точки зрения "сервера" гейтвей это клиент)

гейтвей же у кого-то запрашивает данные, значит он клиент

а сервер тот кто обрабатывает

http://seregazhuk.github.io/2017/05/04/di-smells/

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

про "слишком много зависимостей" - это намек на нарушение open/close и/или SRP

ну короч... не сказал бы что тут именно di smell, просто хреновая работа с зависимостями

ну терминология может быть не совсем точная, но в целом мысли верные

https://www.youtube.com/watch?v=GAFZcYlO5S0

на вот лучше

спасибо, послушаю вечером

https://8thlight.com/blog/uncle-bob/2013/03/08/AnOpenAndClosedCase.html

...был молод и впечатлителен в свои 43 :)

мне есть к чему стремиться )

интерфейсы и ооп: еще один взгляд https://github.com/michaelficarra/ecmascript-interfaces-proposal