Сообщение Re[10]: Книги по enterprise архитектуре основанные на пример от 09.12.2021 13:38
Изменено 09.12.2021 13:39 vsb
Re[10]: Книги по enterprise архитектуре основанные на примера
Здравствуйте, gyraboo, Вы писали:
G>Тут я согласен — это сложные вещи. Как кстати и DDD. Но мне кажется, что появление легковесных потоков твои проблемы не решит, т.к. тебе всё равно придется решать те же проблемы. Упрощение может появится только если ты перестанешь думать и решать какие-то из проблем, затронутых реактивностью. "Нет кода — нет проблемы", но в этом случае твоя система просто не будет обладать рядом свойств. Скажем, ты можешь отказаться реализовывать устойчивость системы. Твой нереактивный код действительно станет проще. Но если встанет-таки задача реализовать устойчивость, ты либо нагородишь своих (тоже ведь наверняка сложных!) костылей, либо возьмешь готовые решения от реактивности (тоже сложные, но хотя бы проработанные и стандартные, например шаблоны Circuit Breaker или Bulkhead).
Мы просто смотрим на это с разных сторон.
Мне не нужна эта устойчивость. Точней нужна, но я не вижу ничего, что мешает мне делать устойчивые системы без реактивщины. Если ты приведёшь конкретный пример, я попробую ответить. Я в курсе про всякие backpressure, но оно всё решается буферами и откидыванием запросов при переполнении буферов (и повторами с другой стороны). И с легковесными потоками это всё естественным образом работает.
Реактивщину используют, т.к. кто-то сказал, что поток на соединение это не масштабируется. А все весь второй фейсбук пишут, причём который должен работать на ноутбуке. А в реактивщине типа потоки используются более разумно, то-сё. И наш сервис сможет обрабатывать миллионы соединений. А с потоком на запрос — всего лишь тысячи. Вот этого наслушаются и начинают городить эту реактивщину. При том, что простой дубовый код на Spring MVC по факту работает ровно так же, только пишется проще и приносит меньше проблем. Но, видимо, неистребим дух написания хитрого запутанного кода. И я даже не против этого явления, это как с этими модными streams делают в 5 строчек то, что с циклом делается в 4, но эта сложность скрыта внутри метода и её никто не видит, а с реактивщиной оно просачивается во все интерфейсы и архитектуру.
И вот с легковесными потоками оно всё начнёт масштабироваться нормально и про реактивщину забудут. Ну я надеюсь, по крайней мере.
Я могу предположить, что есть в каких-нибудь одноклассниках сервис, который реально реактивно тарабанит миллионы запросов, и это там надо. Но это очень нишевой случай. С которым надо разбираться, когда ты в этот нишевой случай упёрся. И привносить эту сложность в проект, тщательно изолированную. Но не раньше.
Могу предложить ещё такой взгляд. Есть язык голанг. В нём легковесные потоки изначально. И насколько популярны в среднестатистическом голанг-приложении реактивные библиотеки (которые, конечно, есть). Я вот, честно, не знаю и было бы интересно услышать.
А в той же Java есть Spring, на котором все пишут. И который RestClient сначала объявил устаревшим, потом одумался и переобъявил в некоем статусе maintained, но всё же WebClient таки является официальной идеологической заменой и теперь всем предлагается им пользоваться, вставляя `block()` в каждый вызов. Что лично меня слегка раздражает.
G>Тут я согласен — это сложные вещи. Как кстати и DDD. Но мне кажется, что появление легковесных потоков твои проблемы не решит, т.к. тебе всё равно придется решать те же проблемы. Упрощение может появится только если ты перестанешь думать и решать какие-то из проблем, затронутых реактивностью. "Нет кода — нет проблемы", но в этом случае твоя система просто не будет обладать рядом свойств. Скажем, ты можешь отказаться реализовывать устойчивость системы. Твой нереактивный код действительно станет проще. Но если встанет-таки задача реализовать устойчивость, ты либо нагородишь своих (тоже ведь наверняка сложных!) костылей, либо возьмешь готовые решения от реактивности (тоже сложные, но хотя бы проработанные и стандартные, например шаблоны Circuit Breaker или Bulkhead).
Мы просто смотрим на это с разных сторон.
Мне не нужна эта устойчивость. Точней нужна, но я не вижу ничего, что мешает мне делать устойчивые системы без реактивщины. Если ты приведёшь конкретный пример, я попробую ответить. Я в курсе про всякие backpressure, но оно всё решается буферами и откидыванием запросов при переполнении буферов (и повторами с другой стороны). И с легковесными потоками это всё естественным образом работает.
Реактивщину используют, т.к. кто-то сказал, что поток на соединение это не масштабируется. А все весь второй фейсбук пишут, причём который должен работать на ноутбуке. А в реактивщине типа потоки используются более разумно, то-сё. И наш сервис сможет обрабатывать миллионы соединений. А с потоком на запрос — всего лишь тысячи. Вот этого наслушаются и начинают городить эту реактивщину. При том, что простой дубовый код на Spring MVC по факту работает ровно так же, только пишется проще и приносит меньше проблем. Но, видимо, неистребим дух написания хитрого запутанного кода. И я даже не против этого явления, это как с этими модными streams делают в 5 строчек то, что с циклом делается в 4, но эта сложность скрыта внутри метода и её никто не видит, а с реактивщиной оно просачивается во все интерфейсы и архитектуру.
И вот с легковесными потоками оно всё начнёт масштабироваться нормально и про реактивщину забудут. Ну я надеюсь, по крайней мере.
Я могу предположить, что есть в каких-нибудь одноклассниках сервис, который реально реактивно тарабанит миллионы запросов, и это там надо. Но это очень нишевой случай. С которым надо разбираться, когда ты в этот нишевой случай упёрся. И привносить эту сложность в проект, тщательно изолированную. Но не раньше.
Могу предложить ещё такой взгляд. Есть язык голанг. В нём легковесные потоки изначально. И насколько популярны в среднестатистическом голанг-приложении реактивные библиотеки (которые, конечно, есть). Я вот, честно, не знаю и было бы интересно услышать.
А в той же Java есть Spring, на котором все пишут. И который RestClient сначала объявил устаревшим, потом одумался и переобъявил в некоем статусе maintained, но всё же WebClient таки является официальной идеологической заменой и теперь всем предлагается им пользоваться, вставляя `block()` в каждый вызов. Что лично меня слегка раздражает.
Re[10]: Книги по enterprise архитектуре основанные на пример
Здравствуйте, gyraboo, Вы писали:
G>Тут я согласен — это сложные вещи. Как кстати и DDD. Но мне кажется, что появление легковесных потоков твои проблемы не решит, т.к. тебе всё равно придется решать те же проблемы. Упрощение может появится только если ты перестанешь думать и решать какие-то из проблем, затронутых реактивностью. "Нет кода — нет проблемы", но в этом случае твоя система просто не будет обладать рядом свойств. Скажем, ты можешь отказаться реализовывать устойчивость системы. Твой нереактивный код действительно станет проще. Но если встанет-таки задача реализовать устойчивость, ты либо нагородишь своих (тоже ведь наверняка сложных!) костылей, либо возьмешь готовые решения от реактивности (тоже сложные, но хотя бы проработанные и стандартные, например шаблоны Circuit Breaker или Bulkhead).
Мы просто смотрим на это с разных сторон.
Мне не нужна эта устойчивость. Точней нужна, но я не вижу ничего, что мешает мне делать устойчивые системы без реактивщины. Если ты приведёшь конкретный пример, я попробую ответить. Я в курсе про всякие backpressure, но оно всё решается буферами и откидыванием запросов при переполнении буферов (и повторами с другой стороны). И с легковесными потоками это всё естественным образом работает.
Реактивщину используют, т.к. кто-то сказал, что поток на соединение это не масштабируется. А все ведь второй фейсбук пишут, причём который должен работать на ноутбуке. А в реактивщине типа потоки используются более разумно, то-сё. И наш сервис сможет обрабатывать миллионы соединений. А с потоком на запрос — всего лишь тысячи. Вот этого наслушаются и начинают городить эту реактивщину. При том, что простой дубовый код на Spring MVC по факту работает ровно так же, только пишется проще и приносит меньше проблем. Но, видимо, неистребим дух написания хитрого запутанного кода. И я даже не против этого явления, это как с этими модными streams делают в 5 строчек то, что с циклом делается в 4, но эта сложность скрыта внутри метода и её никто не видит, а с реактивщиной оно просачивается во все интерфейсы и архитектуру.
И вот с легковесными потоками оно всё начнёт масштабироваться нормально и про реактивщину забудут. Ну я надеюсь, по крайней мере.
Я могу предположить, что есть в каких-нибудь одноклассниках сервис, который реально реактивно тарабанит миллионы запросов, и это там надо. Но это очень нишевой случай. С которым надо разбираться, когда ты в этот нишевой случай упёрся. И привносить эту сложность в проект, тщательно изолированную. Но не раньше.
Могу предложить ещё такой взгляд. Есть язык голанг. В нём легковесные потоки изначально. И насколько популярны в среднестатистическом голанг-приложении реактивные библиотеки (которые, конечно, есть). Я вот, честно, не знаю и было бы интересно услышать.
А в той же Java есть Spring, на котором все пишут. И который RestClient сначала объявил устаревшим, потом одумался и переобъявил в некоем статусе maintained, но всё же WebClient таки является официальной идеологической заменой и теперь всем предлагается им пользоваться, вставляя `block()` в каждый вызов. Что лично меня слегка раздражает.
G>Тут я согласен — это сложные вещи. Как кстати и DDD. Но мне кажется, что появление легковесных потоков твои проблемы не решит, т.к. тебе всё равно придется решать те же проблемы. Упрощение может появится только если ты перестанешь думать и решать какие-то из проблем, затронутых реактивностью. "Нет кода — нет проблемы", но в этом случае твоя система просто не будет обладать рядом свойств. Скажем, ты можешь отказаться реализовывать устойчивость системы. Твой нереактивный код действительно станет проще. Но если встанет-таки задача реализовать устойчивость, ты либо нагородишь своих (тоже ведь наверняка сложных!) костылей, либо возьмешь готовые решения от реактивности (тоже сложные, но хотя бы проработанные и стандартные, например шаблоны Circuit Breaker или Bulkhead).
Мы просто смотрим на это с разных сторон.
Мне не нужна эта устойчивость. Точней нужна, но я не вижу ничего, что мешает мне делать устойчивые системы без реактивщины. Если ты приведёшь конкретный пример, я попробую ответить. Я в курсе про всякие backpressure, но оно всё решается буферами и откидыванием запросов при переполнении буферов (и повторами с другой стороны). И с легковесными потоками это всё естественным образом работает.
Реактивщину используют, т.к. кто-то сказал, что поток на соединение это не масштабируется. А все ведь второй фейсбук пишут, причём который должен работать на ноутбуке. А в реактивщине типа потоки используются более разумно, то-сё. И наш сервис сможет обрабатывать миллионы соединений. А с потоком на запрос — всего лишь тысячи. Вот этого наслушаются и начинают городить эту реактивщину. При том, что простой дубовый код на Spring MVC по факту работает ровно так же, только пишется проще и приносит меньше проблем. Но, видимо, неистребим дух написания хитрого запутанного кода. И я даже не против этого явления, это как с этими модными streams делают в 5 строчек то, что с циклом делается в 4, но эта сложность скрыта внутри метода и её никто не видит, а с реактивщиной оно просачивается во все интерфейсы и архитектуру.
И вот с легковесными потоками оно всё начнёт масштабироваться нормально и про реактивщину забудут. Ну я надеюсь, по крайней мере.
Я могу предположить, что есть в каких-нибудь одноклассниках сервис, который реально реактивно тарабанит миллионы запросов, и это там надо. Но это очень нишевой случай. С которым надо разбираться, когда ты в этот нишевой случай упёрся. И привносить эту сложность в проект, тщательно изолированную. Но не раньше.
Могу предложить ещё такой взгляд. Есть язык голанг. В нём легковесные потоки изначально. И насколько популярны в среднестатистическом голанг-приложении реактивные библиотеки (которые, конечно, есть). Я вот, честно, не знаю и было бы интересно услышать.
А в той же Java есть Spring, на котором все пишут. И который RestClient сначала объявил устаревшим, потом одумался и переобъявил в некоем статусе maintained, но всё же WebClient таки является официальной идеологической заменой и теперь всем предлагается им пользоваться, вставляя `block()` в каждый вызов. Что лично меня слегка раздражает.