Size: a a a

2020 September 23

AN

Alexander Nozik in Kotlin Moscow
Alexander Kirillov
У меня в проекте и то и то используется. В принципе, обе библиотеки примерно об одном и том же, кстати и интегрируются между собой хорошо. Какие то вещи проще делать через reactor, какие-то через корутины. Например, в корутинах есть акторы, на реакторе такое можно сделать, как-то через контекст пропихивать состояние, но не так красиво как в акторах с тейлреком. С другой стороны в реакторе ооочень много полезных операторов, таких даже в корутиновых flow нет. Например у нас на реакторе построена агрегация данных для ui, причем достаточно нетривиальная в плане разбивки данных по батчам в зависимости от самих данных и ряда других факторов. Вообще, судя по всему за корутинами будущее ибо читать проще, особенно с flow, но в реакторе очень уж классные операторы
Операторы во Flow добавляются в одно касание. Для этого не надо переписывать библиотеку. Так что если не хватает пары операторов, проще их дописать
источник

Ⓢⓔⓡⓖ in Kotlin Moscow
Mplain
Круто :)
И что, ты используешь корутины? suspend, await, вот это все?
А то я по-старинке, map-flatMap, и так и не смог для себя пока обосновать полезность корутин
Даже если нужно что-то заасинхронить, использую Mono.defer{}
Некоторые ещё для себя не смогли обосновать полезность webflux
источник

Ⓢⓔⓡⓖ in Kotlin Moscow
источник

AN

Alexander Nozik in Kotlin Moscow
Ⓢⓔⓡⓖ
Некоторые ещё для себя не смогли обосновать полезность webflux
Некоторые пишут на битриксе 🤷‍♂️
источник

MB

Maksim B. in Kotlin Moscow
Ⓢⓔⓡⓖ
Некоторые ещё для себя не смогли обосновать полезность webflux
Я на втором проекте пишу на webflux и понял, что почти всегда обоснование такое - "поиграться" (на оба проекта пришел не со старта). Скорость разработки сильно падает, много граблей, для типового проекта больше вреда, чем пользы. Помню, что кто-то из разработчиков webflux сказал, что-то типо "если у вас проект не уровня netflix, то вам не нужен webflux".
источник

MB

Maksim B. in Kotlin Moscow
Грабли разного рода попадаются, из примеров: если в webflux проекте используются корутины, то не получится подключить spring sleuth и команда должна идти и велосипедить, что-то свое))
источник

Ⓢⓔⓡⓖ in Kotlin Moscow
Да согласен
источник

Ⓢⓔⓡⓖ in Kotlin Moscow
Главный тормоз развития новых технологий типа корутин - это то что ЗП разработчиков выше стоимости серверов. Пока проблему производительности бэкэенда можно быстро решить закупкой доп железа, ни вебфлукс, ни корутины на бэке не очень востребованы
источник

AN

Alexander Nozik in Kotlin Moscow
Ⓢⓔⓡⓖ
Главный тормоз развития новых технологий типа корутин - это то что ЗП разработчиков выше стоимости серверов. Пока проблему производительности бэкэенда можно быстро решить закупкой доп железа, ни вебфлукс, ни корутины на бэке не очень востребованы
Ну любая новая технология - это тормоза на старте. Я не думаю, что вопрос тут в производительности. Скорее все-таки в гибкости. Если надо круды клепать - магия на аннотациях будет работать лучше. Если надо что-то более сложно, все эти "удобства" спринга могут быть в минус, а не в плюс.
источник

SB

Sergey Bezrukov in Kotlin Moscow
Ⓢⓔⓡⓖ
Главный тормоз развития новых технологий типа корутин - это то что ЗП разработчиков выше стоимости серверов. Пока проблему производительности бэкэенда можно быстро решить закупкой доп железа, ни вебфлукс, ни корутины на бэке не очень востребованы
Для 99% (это пессимистично, на самом деле там ещё девятки после запятой) проектов из числа тех, что пишут на спрингбуте и подобном, асинхронщина на беке с целью "экономии тредов" нафиг не нужна, они НИКОГДА не упрутся в эту проблему на стандартном железе, никаких "закупок доп. железа" не потребуется.
источник

AL

Alexander Larin in Kotlin Moscow
вроде же новая спецификация сервлетов дает некую асинхронщину и без вебфлюкса?
источник

MB

Maksim B. in Kotlin Moscow
Sergey Bezrukov
Для 99% (это пессимистично, на самом деле там ещё девятки после запятой) проектов из числа тех, что пишут на спрингбуте и подобном, асинхронщина на беке с целью "экономии тредов" нафиг не нужна, они НИКОГДА не упрутся в эту проблему на стандартном железе, никаких "закупок доп. железа" не потребуется.
Очень точно подмечено. А деятели, которые выбирают эти технологии ловко обосновывают свои решения, играются и уходят.
источник

N

Nort in Kotlin Moscow
Sergey Bezrukov
Для 99% (это пессимистично, на самом деле там ещё девятки после запятой) проектов из числа тех, что пишут на спрингбуте и подобном, асинхронщина на беке с целью "экономии тредов" нафиг не нужна, они НИКОГДА не упрутся в эту проблему на стандартном железе, никаких "закупок доп. железа" не потребуется.
Мы уже упёрлись на 2000 рпс
источник

AN

Alexander Nozik in Kotlin Moscow
Maksim B.
Очень точно подмечено. А деятели, которые выбирают эти технологии ловко обосновывают свои решения, играются и уходят.
Ну и да, половина веба на джанго, вторая половина на ноде. Перфоранс - это миф. Но при этом это не отменяет того, что я писал выше. Как только это не круды, быстро оказывается что костыльность растет.
источник

Ⓢⓔⓡⓖ in Kotlin Moscow
Alexander Nozik
Ну любая новая технология - это тормоза на старте. Я не думаю, что вопрос тут в производительности. Скорее все-таки в гибкости. Если надо круды клепать - магия на аннотациях будет работать лучше. Если надо что-то более сложно, все эти "удобства" спринга могут быть в минус, а не в плюс.
Ну, я вот упирался
источник

Ⓢⓔⓡⓖ in Kotlin Moscow
Проблема решена закупкой двух серверов, и это в 5 раз дешевле заменой софта
источник

AN

Alexander Nozik in Kotlin Moscow
Ⓢⓔⓡⓖ
Ну, я вот упирался
Ну а кто мешает на спринге тред-пулы использовать? Я не говорю, что не надо переходить на корутины. Наоборот, я говорю. что надо. Просто аргумент производительности - сильно не первый
источник

SB

Sergey Bezrukov in Kotlin Moscow
Nort
Мы уже упёрлись на 2000 рпс
Да, с таким уровнем нагрузки это уже, наверное, имеет смысл.
А у вас, если не секрет, сколько времени занимает обработка одного запроса и на что оно тратится (ЦПУ, диск, ожидание ответа от внешних систем типа БД)?
И ещё интересно, у вас 2000 рпс на один ящик? Или их несколько? И с какого кол-ва одновременно обрабатываемых запросов начались проблемы?  
Простите моё любопытство, но нечасто встретишь проекты на спрингбуте с такими нагрузками на один ящик.
источник

Ⓢⓔⓡⓖ in Kotlin Moscow
В основном в бд все тормоза, а там в свою очередь - в дисках (которые в свою очередь крутящиеся, ибо ssd доверия нет)
источник

MB

Maksim B. in Kotlin Moscow
К слову о БД: выбирая webflux, ты уже обязан тянуть какую-нибудь монгу в проект, вместо чего-то реляционного (да, есть R2DBC, пробовали, год назад было очень сыро).
источник