Статья совсем не актуальная уже совсем. Новое начинать на ОСС стеке смысла нет, есть Кубернетис и Истио.
Хистрик уже мертв. Да и когда был жив то был очень медленный и тяжеловесен.
в том то и дело что ИМХО. Но я изначально говорил что суть написание кода остается такой же как и в Джаве. Те это не какой то сдвиг парадигмы как в Расте. А просто сахарка присыпали причем много можно делать на джаве сторонними библиотека или вообще вкусовщина.
корутины,
Я живу в радость с реактивными библиотеками как Lettuce, Vert.x, AWS SDK v2 и тд
где все либо с коробки Mono/Flux либо оборачивается легко. И зачем они мне?
А взять какой нибудь Хибернейт, то его не прикрутишь к корутинам и не сделаешь в один миг асинхронным и не блокирующим.
мультиплатформенность кода
у нас есть Graal или Vertx
Те да все эти фичи есть и их классно использовать под Андроид а не мудохаться с обрезаной джавой. Но на бэкенде я не вижу смысла вносить новый язык, который все равно будет очень плотно пересекаться с джавой и требовать знание и понимание работы джавовских библиотек.
Вы действительно думаете, что это настолько существенное различие что вы напишите этот код в два раза быстрее и он еще работать будет быстрее?
Когда вы пишите на языке постоянно то вы вообще не обращаете внимание там id?или Optional.ofNullable(id).
Так же на мой вкус вот такой код id?.toInt() ?: -1 больше смахивает на брейнфак в то время как Джаовский делает тоже самое и также в одну строку, но читая его все просто и понятно Optional.ofNullable(id).map(Integer::valueOf).orElse(-1)
И даже два наших мнения показывают что ваши утверждения субъективные.
П.С. и вообще в java я возьму mapstruct и не буду писать весь этот код :)))) В этом и сила java, что всегда можно сделать разными путями.
Мне кажется насчет того что на Котлин писать быстрее это самовнушение.
Ваш код
data class StorableObject(
var id: String? = null,
var data: String? = null
) {
// Место размещения мапера зависит от задачи
constructor(wm: WorkModel): this(
id = wm.id.takeIf { it != -1 }?.toString(),
data = wm.data.takeIf { it.isNotBlank() }
)
// Место размещения мапера зависит от задачи
fun toWorkModel(): WorkModel = WorkModel(
id = id?.toInt() ?: -1,
data = data ?: ""
)
}
легко пишется на Джава в том же самом подходе.
@Data
public class StorageObject {
private String id;
private String data;
public StorageObject(@NonNull WorkModel workModel) {
id = Optional.ofNullable(workModel.id).filter(value -> value != -1).map(String::valueOf).orElse(null);
data = Optional.ofNullable(workModel.data).filter(not(String::isBlank)).orElse(null);
}
public WorkModel toWorkModel() {
return new WorkModel(
Optional.ofNullable(id).map(Integer::valueOf).orElse(-1),
Optional.ofNullable(data).orElse("")
);
}
}
Да, чуть больше символов, но это как по мне вообще мелочь. Тк именно подход как делать один и тот же.
Джаву все вытесняют и вытесняют а вытеснить не могут. Потому что на мой счет она универсальная для разработки бизнес приложений — и кросплатформеная и быстрая и туева куча библиотек и можно писать умно и быстро, а можно взять новичка и дать ему что то лабать и оно даже будет как то работать.
Расскажу за свой пример никак не связанный с авторским.
Есть сервис который должен отсылать сотни пуш нотификаций на мобильные устройства в секунду. и есть внешний провайдер через который это надо делать, с ним подписан контракт и на его мобильный сдк завязано приложение и с него не спрыгнуть. И для этого провайдера вполне нормальная ситуация когда он вместо ~100ms на запрос делает по 6-20 сек. И пофиг сколько я процессоров накидаю в микросервис, все просто будет отжирать память и ждать ответа. Так же забиваются хттп потоки для веб сервера и он просто не сможет обрабатывать новые входящие сообщения. И простое добавление реактивщины избавляет от этих проблем — тк надо всего пару потоков на асинхронный прием запроса, обработки и потом асинхронный запрос к провайдеру.
Наш сервис может обслуживать кучу клиентов, памяти жрем в разы меньше, инстансов нужно меньше.
Я пытался к проду прикрутить где то пару месяцев назад и вылазили странные ошибки. Например возникала ошибка что данных для Моно есть несколько а не одно как должно быть Ошибки поправили, но мне не хотелось выкатывать такое нестабильное поведение на прод.
Поэтому просто сделал прослойку которая заворачивает vert.x постгрес клиент в Mono/Flux и живу горя не зная.
Как вы делаете привязку различных логов к одному запросу? Тк запрос может скакать по потокам то MDC к примеру не работает. У нас я сделал в лоб через
Hooks.onEachOperator(...);
Оно нормально работает, но меня напрягает что логи пишутся в некоторых случаях, а оборачиваем в свою логику по определению и выставлению MDC мы для кадого Mono/Flux
Я делал один запрос в котором много возможных вариантов через jOOQ и сгенерить SQL, но большинство запросов просто руками писаные в Repository объекте сидят. У меня специфика, что много микросервисов и схемы простые — не больше 10 таблиц в схеме.
Если у вас Хибернейт то вам уже производительность по определению не приоритет :)
Но когда R2DBC будет готово для продакшена то к нему есть Спринг Дата
Да на 16 ядрах уже можно писать на джаве, а все остальное это мелочь и не достойна этого славного языка. Пусть го-писатели мучаются в докере и считают каждый доллар.
Вы на ходу сами себе придумываете что-то, то классическое маштабирование которое ничем не отличается от плодим кучу мелких машин
Наш спор ограничивается одним инстансом с указанными параметрами.
Это касается R2DBC про который я не раз говорил в комментариях к схожим статьям, что он медленный и авторы этого не скрывают. И в продакшене его еще рано использовать.
Так же в этой статье была приведена ссылка на производительность verxt client'a — https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=db
так же мы с вами говорим вообще за подход когда вся система реативная или когда поток потоком погоняет.
Ага — удачи в бизнесе с таким подходом. А давайте это забахаем на Расте, а это на Скале, вот этот кусок ради интереса сделаем на Хаскеле.
Мне просто без разницы на чем писать. На чем надо на том и напишу. Если не писал до этого нуу окей, просто будет более долгий старт.
Делаем два ендпоинта
в один случайным образом постим число 1..100 — оно записывается в Постгрес где ид это число, а второе поле текущий таймстемп, а так же эти же данные кладем в редис с ттл в 1 сек
вычитываем записи по случайному числу 1..100 — если есть то вовращаем данные с редиса, если там нет то с постгреса.
Для сравнения нужно, чтобы реализации делали одно и то же. Если хотите чтобы я написал ну окей, я могу набросать, но вопрос упирается что надо?
А у вас все проекты вида тратьте денег мульоны, нам пофиг на расходы? Или понять что хорошо когда бэкенд на одном языке написан и людей можно перекидывать с проекта на проект?
Если у меня есть ограничения про процессору и памяти, я бы сначала подумал зачем мне там вообще java.
Смотрите свое самое первое сообщение и думайте.
Как обычно не читай сразу отвечай. Еще раз я сейчас пишу как раз под non-blocking со всеми вытекающими оттуда проблемами.
Не, никто за вас свою часть не будет делать и тем более за интерес. А то накинуть на вентилятор это вы можете и писать кучу комментариев время есть. А как сделать так пусть другие?
Статья совсем не актуальная уже совсем. Новое начинать на ОСС стеке смысла нет, есть Кубернетис и Истио.
Хистрик уже мертв. Да и когда был жив то был очень медленный и тяжеловесен.
в том то и дело что ИМХО. Но я изначально говорил что суть написание кода остается такой же как и в Джаве. Те это не какой то сдвиг парадигмы как в Расте. А просто сахарка присыпали причем много можно делать на джаве сторонними библиотека или вообще вкусовщина.
Я живу в радость с реактивными библиотеками как Lettuce, Vert.x, AWS SDK v2 и тд
где все либо с коробки
Mono/Fluxлибо оборачивается легко. И зачем они мне?А взять какой нибудь Хибернейт, то его не прикрутишь к корутинам и не сделаешь в один миг асинхронным и не блокирующим.
у нас есть Graal или Vertx
Те да все эти фичи есть и их классно использовать под Андроид а не мудохаться с обрезаной джавой. Но на бэкенде я не вижу смысла вносить новый язык, который все равно будет очень плотно пересекаться с джавой и требовать знание и понимание работы джавовских библиотек.
П.С. А если вы сходите в Го группы то вам расскажут, что https://github.com/bxcodec/go-clean-arch/blob/master/article/usecase/article_ucase.go#L33-L82 это нормально для Го,
а вот такое на Джаве
это куча библиотек и не Го стиль :)))
Но при этом Го тоже должен подвинуть Джаву :))))
Вы действительно думаете, что это настолько существенное различие что вы напишите этот код в два раза быстрее и он еще работать будет быстрее?
Когда вы пишите на языке постоянно то вы вообще не обращаете внимание там
id?илиOptional.ofNullable(id).Так же на мой вкус вот такой код
id?.toInt() ?: -1больше смахивает на брейнфак в то время как Джаовский делает тоже самое и также в одну строку, но читая его все просто и понятноOptional.ofNullable(id).map(Integer::valueOf).orElse(-1)И даже два наших мнения показывают что ваши утверждения субъективные.
П.С. и вообще в java я возьму mapstruct и не буду писать весь этот код :)))) В этом и сила java, что всегда можно сделать разными путями.
Мне кажется насчет того что на Котлин писать быстрее это самовнушение.
Ваш код
легко пишется на Джава в том же самом подходе.
Да, чуть больше символов, но это как по мне вообще мелочь. Тк именно подход как делать один и тот же.
Джаву все вытесняют и вытесняют а вытеснить не могут. Потому что на мой счет она универсальная для разработки бизнес приложений — и кросплатформеная и быстрая и туева куча библиотек и можно писать умно и быстро, а можно взять новичка и дать ему что то лабать и оно даже будет как то работать.
У нас в коде наоборот,
onNextне особо надо логировать, а вот в местах бизнес логики такого много.Это не особо удобно, сравните
с просто
log.info('some'):так же зачастую надо логировать не только на
onNextно и внутриflatMapи тогда приходиться закручивать все вили
mapтогда надо брать и переделывать ее наflatMapвообщем вместо простой вещи получается лапша за которой прячется бизнес логика.
Расскажу за свой пример никак не связанный с авторским.
Есть сервис который должен отсылать сотни пуш нотификаций на мобильные устройства в секунду. и есть внешний провайдер через который это надо делать, с ним подписан контракт и на его мобильный сдк завязано приложение и с него не спрыгнуть. И для этого провайдера вполне нормальная ситуация когда он вместо ~100ms на запрос делает по 6-20 сек. И пофиг сколько я процессоров накидаю в микросервис, все просто будет отжирать память и ждать ответа. Так же забиваются хттп потоки для веб сервера и он просто не сможет обрабатывать новые входящие сообщения. И простое добавление реактивщины избавляет от этих проблем — тк надо всего пару потоков на асинхронный прием запроса, обработки и потом асинхронный запрос к провайдеру.
Наш сервис может обслуживать кучу клиентов, памяти жрем в разы меньше, инстансов нужно меньше.
Вот в подобной теме ссылки дали
https://habr.com/ru/post/500446/#comment_21678412
или вот еще пример https://github.com/r2dbc/r2dbc-postgresql/issues/138
Я пытался к проду прикрутить где то пару месяцев назад и вылазили странные ошибки. Например возникала ошибка что данных для Моно есть несколько а не одно как должно быть Ошибки поправили, но мне не хотелось выкатывать такое нестабильное поведение на прод.
Поэтому просто сделал прослойку которая заворачивает vert.x постгрес клиент в
Mono/Fluxи живу горя не зная.не пользуйте R2DBC в продакшене, он медленный и еще не стабильный.
для постгреса наилучший вариант https://vertx.io/docs/vertx-pg-client/java/
Как вы делаете привязку различных логов к одному запросу? Тк запрос может скакать по потокам то MDC к примеру не работает. У нас я сделал в лоб через
Оно нормально работает, но меня напрягает что логи пишутся в некоторых случаях, а оборачиваем в свою логику по определению и выставлению MDC мы для кадого
Mono/FluxТо что вы написали это все правда. Вопрос был в другом зачем уходить на
когда описанные асинхронные клиенты удобней в плане работы с АПИ.
Я часто видел стектрейсы гораздо длинней на обыкновенной джаве :)))
А почему сейчас нельзя взять вам AsyncHttpClient или WebClient
Я делал один запрос в котором много возможных вариантов через jOOQ и сгенерить SQL, но большинство запросов просто руками писаные в Repository объекте сидят. У меня специфика, что много микросервисов и схемы простые — не больше 10 таблиц в схеме.
Можно попробовать просто генерить SQL с jOOQ и скармливать его Vert.x
Если у вас Хибернейт то вам уже производительность по определению не приоритет :)
Но когда R2DBC будет готово для продакшена то к нему есть Спринг Дата
Да на 16 ядрах уже можно писать на джаве, а все остальное это мелочь и не достойна этого славного языка. Пусть го-писатели мучаются в докере и считают каждый доллар.
Вы на ходу сами себе придумываете что-то, то классическое маштабирование которое ничем не отличается от плодим кучу мелких машин
Наш спор ограничивается одним инстансом с указанными параметрами.
Это касается R2DBC про который я не раз говорил в комментариях к схожим статьям, что он медленный и авторы этого не скрывают. И в продакшене его еще рано использовать.
Так же в этой статье была приведена ссылка на производительность verxt client'a — https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=db
так же мы с вами говорим вообще за подход когда вся система реативная или когда поток потоком погоняет.
Ага — удачи в бизнесе с таким подходом. А давайте это забахаем на Расте, а это на Скале, вот этот кусок ради интереса сделаем на Хаскеле.
Делаем два ендпоинта
А у вас все проекты вида тратьте денег мульоны, нам пофиг на расходы? Или понять что хорошо когда бэкенд на одном языке написан и людей можно перекидывать с проекта на проект?
Смотрите свое самое первое сообщение и думайте.
Не, никто за вас свою часть не будет делать и тем более за интерес. А то накинуть на вентилятор это вы можете и писать кучу комментариев время есть. А как сделать так пусть другие?