Size: a a a

2020 June 07

SP

Stanislav Popov in rust_offtopic
ладно там у скриптодетей нет типов и им сваггер заменяет интерфейсы внешние
источник

p

polunin.ai in rust_offtopic
Stanislav Popov
зачем нужны микросервисы когда есть типы и каналы?
легче масштабируется
источник

p

polunin.ai in rust_offtopic
и разрабатывается
источник

p

polunin.ai in rust_offtopic
и поддерживается
источник

DS

Doge Shibu in rust_offtopic
Stanislav Popov
зачем нужны микросервисы когда есть типы и каналы?
Сильно проще код, процессы и команды организовывать
источник

VS

Victor Sapiens in rust_offtopic
Doge Shibu
Тут основная проблема, что ты в такой архитектуре получишь просто дикое латенси на любую нетривиальную операцию.
Ну не такую большую как тебе кажется. Вообше с твоими мышлением - делай монолит с всяким голым SQL без ORM и не парься.
источник

p

polunin.ai in rust_offtopic
Victor Sapiens
Ну не такую большую как тебе кажется. Вообше с твоими мышлением - делай монолит с всяким голым SQL без ORM и не парься.
ну он это и говорит тут постоянно)
источник

DS

Doge Shibu in rust_offtopic
polunin.ai
ну он это и говорит тут постоянно)
Ну монолит не обязательно, но делать пустые сервисы без особой логики жалко.
источник

VS

Victor Sapiens in rust_offtopic
@DogeShibu  У нас с тобой вообще цели разные. Я за Дерево микросервисов и ORM вроде EF и Чистую Архитектуру. Ты вообще про другое по ходу.
источник

DS

Doge Shibu in rust_offtopic
Victor Sapiens
@DogeShibu  У нас с тобой вообще цели разные. Я за Дерево микросервисов и ORM вроде EF и Чистую Архитектуру. Ты вообще про другое по ходу.
Я за то, чтобы проектировать приложения сразу помня про перформанс.

Это куда проще, чем потом с пылающей задницей оптимизировать.

Причем, архитектура внутри приложения обычно от этого не сильно страдает. Тот же DAL всё равно изолирует весь SQL в себе, а на остальную архитектуру такие вещи влияния особо не оказывают.

Те же микросервисы - они имеют смысл, но с ними тоже важен баланс, т.к. их инфраструктурная стоимость всё равно велика.
источник

VS

Victor Sapiens in rust_offtopic
Doge Shibu
Я за то, чтобы проектировать приложения сразу помня про перформанс.

Это куда проще, чем потом с пылающей задницей оптимизировать.

Причем, архитектура внутри приложения обычно от этого не сильно страдает. Тот же DAL всё равно изолирует весь SQL в себе, а на остальную архитектуру такие вещи влияния особо не оказывают.

Те же микросервисы - они имеют смысл, но с ними тоже важен баланс, т.к. их инфраструктурная стоимость всё равно велика.
Был бы для меня важен перформанс - Яб как ты на Rust писал бы.
источник

DS

Doge Shibu in rust_offtopic
Victor Sapiens
Был бы для меня важен перформанс - Яб как ты на Rust писал бы.
Эти вещи актуальны и для io-bound задач в той же мере.

Вон, почитай как в stack overflow пишут на C# и экономят на железе за счёт кода сразу написанного с учётом вопросов производительности
источник

NL

Nick Linker in rust_offtopic
Doge Shibu
Я за то, чтобы проектировать приложения сразу помня про перформанс.

Это куда проще, чем потом с пылающей задницей оптимизировать.

Причем, архитектура внутри приложения обычно от этого не сильно страдает. Тот же DAL всё равно изолирует весь SQL в себе, а на остальную архитектуру такие вещи влияния особо не оказывают.

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

У меня был проект, когда заказчик в какой-то момент решил сделать новостную ленту наподобие того, что было в вк раньше. И эта страничка была одной из самых тяжёлых, для отображения которой требовалось сходить буквально во все (за исключением пары) сервисы. Это была полнейшая жопа.

Конечно об этом надо было думать заранее.
источник

VS

Victor Sapiens in rust_offtopic
Doge Shibu
Эти вещи актуальны и для io-bound задач в той же мере.

Вон, почитай как в stack overflow пишут на C# и экономят на железе за счёт кода сразу написанного с учётом вопросов производительности
Ну для простой системы таким фасадом в котором будут лежать Saga с этапами типо сходи в МС1, сходи с результатом из МС1 в МС2 и с результатом всего этого либо в МС3 либо в МС4 может служить сам Гейтвей
источник

VS

Victor Sapiens in rust_offtopic
Сами МС1, 2, 3 и 4 друг о друге понятия не имеют
источник

VS

Victor Sapiens in rust_offtopic
Хм, я тут подумал. В моём EShopOnBlazor там API это монолит. Наверно напишу статью на его примере как разбить монолит на микросервисы и сделать из монолита Гейтвей + Фасад с Сагами.
источник

DS

Doge Shibu in rust_offtopic
Victor Sapiens
Ну для простой системы таким фасадом в котором будут лежать Saga с этапами типо сходи в МС1, сходи с результатом из МС1 в МС2 и с результатом всего этого либо в МС3 либо в МС4 может служить сам Гейтвей
Ну сага это всё же про поддержку консистетности между разными бд в разных сервисах.

Это далеко не везде актуально
источник

VS

Victor Sapiens in rust_offtopic
Doge Shibu
Ну сага это всё же про поддержку консистетности между разными бд в разных сервисах.

Это далеко не везде актуально
Ну тогда просто Гейтвей который в одном методе Контроллера тупо вызывает МС1, 2, 3, 4 если там надежности не надо особой и можно с нуля все начинать спокойно
источник

VS

Victor Sapiens in rust_offtopic
Doge Shibu
Ну сага это всё же про поддержку консистетности между разными бд в разных сервисах.

Это далеко не везде актуально
Ну не толко БД. Просто когда надо чтобы вот в конце концов выполнился запрос даже если вдруг вырубится МС и запуститься снова тоже удобно. Когда лишние запросы делать не охота и результаты предыдущих сохранить надо как промежуточные данные тоже норм
источник

VS

Victor Sapiens in rust_offtopic
Ну да, большинство проблем решается изначальной идемпотентностью запросов
источник