Если я правильно понял статью (после чтения по диагонали), то у вас используется:
Сервисы связаны в кластер
Шардирование
Local queries / reads
State replication
Recovery через репликацию данных с других инстансов
Что делается "из коробки" (правда подозреваю менее эффективно, хотя интересно было бы сравнить) в Akka с помощью Akka Cluster + Akka Persistence и ещё пары штук возможно.
P.S. Олег, ты чего на "вы", не первый день знакомы ;)
Начиная с Testcontainers 1.12.3, мы добавили "reusable containers", что позволяет переиспользовать контейнер между сессиями тестов при локальной разработке.
Так что теперь не обязательно использовать другой тул :)
За репорт — респект!
Про "мультитредовые тесты" — надеюсь тоже репортил.
По ссылке на TechEmpower (который я кстати не очень люблю, учитывая что он был создан чтобы показать какой их фреймворк быстрый и ни раз был замечен делающим некорректные бенчмарки для других) r2dbc не нашёл.
Опять же, стоит мерять производительность реальных реактивных сервисов (JDBC + Thread Pool vs R2DBC), где каждый вызов JDBC будет идти через context switch т.к. блокировать текущий реактивный поток нельзя.
В "песочнице" R2DBC vs JDBC показывает себя неплохо (особенно с MSSQL, кстати), а так же есть куда оптимизировать. В таких вещах обычно первым идёт "сделать чтобы работало" а потом уже "чтобы быстро".
Конечно, конечно… нет :D
Файберы и корутины упрощают для юзера, а реактивщина — делает чтобы быстро было!
Одно другому не мешает ;)
ИМХО файберы виртуальные потоки только улучшат adoption реактивных технологий — потому что можно будет не бояться "что-то там заблокировать", а всякие flatMapconcatMap превратятся в обычный map.
Как опытный Jenkins-овод, могу заверить:
1) "Groovy не работают в некоторых местах" — это скорее бага, чем особенность, которую они так и не смогли побороть
2) "тратить часы чтобы понять как оно вообще собирается и кто кого зовет" — так же применимо к Jenkinsfile-ам, иногда даже ситуация гораздо хуже, чем в Gradle.
3) "структуру можно полностью переопределить" — это не совсем так. В Gradle действительно можно "пачкать" variable scope, но нельзя, например, переопределить "configurations {}" блок, в итоге имеем структурированность практически как в декларативном Jenkinsfile-е
4) "stages" в Jenkinsfile только если использовать декларативный подход, он не всегда подходит, приходится использовать императивный, и там ад и содомия похлеще Gradle файлов
Надо знать только этот класс, и на нём будут все методы.
И только в этом билдере в статье есть pantonymic
Не совсем. Юзер просто использует $DesiredUserType.Builder и видит все поля, которые можно "настроить" с помощью билдера.
Т.е. пользователь не ищет "а где же настроить pantonymic", он имеет тип, и видит какие параметры этого типа можно установить.
Значительно упрощенный API благодаря этому.
Юзеру не надо знать о всех существующих билдерах, не надо знать в каком из них настаривается foo, а в каком — bar (типичная проблема композиции).
по-моему в вашем примере кол-во "new" удваивается при добавлении нового наследника ;)
А когда пропертей десятки, то такой код начинает пугать. И ещё, у него есть один важный недостаток — при добавлении метода в базовый класс, он не попадает в наследников пока его вручную везде не добавят.
С таким очень сложно работать, нет нормального способа хранить состояние (например, коллекции открытых портов, или переменных окружения), ну и не очевидный способ создания через прокси и вот это вот всё (в PR кстати чуть по-другому это решили)
ну, не решается, скорей просто убирает часть проблемы. Но проблема всё же остаётся, особенно когда на реальных примерах её погонять (прошли через это, был одним из вариантов API)
А http://buildpacks.io рассматривали?
Если я правильно понял статью (после чтения по диагонали), то у вас используется:
Что делается "из коробки" (правда подозреваю менее эффективно, хотя интересно было бы сравнить) в Akka с помощью Akka Cluster + Akka Persistence и ещё пары штук возможно.
P.S. Олег, ты чего на "вы", не первый день знакомы ;)
Выглядит как своя реализация идей, доступных в Akka. Рассматривали её?
С reusable containers Ryuk не будет прибивать контейнеры которые помечены как reusable, в том и смысл :)
Начиная с Testcontainers 1.12.3, мы добавили "reusable containers", что позволяет переиспользовать контейнер между сессиями тестов при локальной разработке.
Так что теперь не обязательно использовать другой тул :)
За репорт — респект!
Про "мультитредовые тесты" — надеюсь тоже репортил.
По ссылке на TechEmpower (который я кстати не очень люблю, учитывая что он был создан чтобы показать какой их фреймворк быстрый и ни раз был замечен делающим некорректные бенчмарки для других) r2dbc не нашёл.
Опять же, стоит мерять производительность реальных реактивных сервисов (JDBC + Thread Pool vs R2DBC), где каждый вызов JDBC будет идти через context switch т.к. блокировать текущий реактивный поток нельзя.
В "песочнице" R2DBC vs JDBC показывает себя неплохо (особенно с MSSQL, кстати), а так же есть куда оптимизировать. В таких вещах обычно первым идёт "сделать чтобы работало" а потом уже "чтобы быстро".
А не поделитесь ссылками чтобы подтвердить своё мнение? На открытые баг репорты, бенчмарки.
А то иначе выглядит как вброс ;)
Конечно, конечно… нет :D
Файберы и корутины упрощают для юзера, а реактивщина — делает чтобы быстро было!
Одно другому не мешает ;)
ИМХО
файберывиртуальные потоки только улучшат adoption реактивных технологий — потому что можно будет не бояться "что-то там заблокировать", а всякиеflatMapconcatMapпревратятся в обычныйmap.Как опытный Jenkins-овод, могу заверить:
1) "Groovy не работают в некоторых местах" — это скорее бага, чем особенность, которую они так и не смогли побороть
2) "тратить часы чтобы понять как оно вообще собирается и кто кого зовет" — так же применимо к Jenkinsfile-ам, иногда даже ситуация гораздо хуже, чем в Gradle.
3) "структуру можно полностью переопределить" — это не совсем так. В Gradle действительно можно "пачкать" variable scope, но нельзя, например, переопределить "configurations {}" блок, в итоге имеем структурированность практически как в декларативном Jenkinsfile-е
4) "stages" в Jenkinsfile только если использовать декларативный подход, он не всегда подходит, приходится использовать императивный, и там ад и содомия похлеще Gradle файлов
А ничего что Jenkinsfile это Groovy?:)
Надо знать только этот класс, и на нём будут все методы.
Не совсем. Юзер просто использует
$DesiredUserType.Builderи видит все поля, которые можно "настроить" с помощью билдера.Т.е. пользователь не ищет "а где же настроить pantonymic", он имеет тип, и видит какие параметры этого типа можно установить.
Значительно упрощенный API благодаря этому.
Юзеру не надо знать о всех существующих билдерах, не надо знать в каком из них настаривается
foo, а в каком —bar(типичная проблема композиции).Это уже не "наследование".
1) дублирование объявлений полей
2) Да.
Даже ваш великий Котлин не спасает от тонны ненужного синтаксиса здесь. Особенно когда таких полей десятки.
по-моему в вашем примере кол-во "new" удваивается при добавлении нового наследника ;)
А когда пропертей десятки, то такой код начинает пугать. И ещё, у него есть один важный недостаток — при добавлении метода в базовый класс, он не попадает в наследников пока его вручную везде не добавят.
Тогда это уже не называется "наследование"
Рассматривали.
С таким очень сложно работать, нет нормального способа хранить состояние (например, коллекции открытых портов, или переменных окружения), ну и не очевидный способ создания через прокси и вот это вот всё (в PR кстати чуть по-другому это решили)
ну, не решается, скорей просто убирает часть проблемы. Но проблема всё же остаётся, особенно когда на реальных примерах её погонять (прошли через это, был одним из вариантов API)
Летали. Знаем.