Если я правильно понял статью (после чтения по диагонали), то у вас используется:
Сервисы связаны в кластер
Шардирование
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)
«Восстание машин» часть 1: continuous delivery для базовых Docker образов
А http://buildpacks.io рассматривали?
Эффективные надежные микросервисы
Если я правильно понял статью (после чтения по диагонали), то у вас используется:
Что делается "из коробки" (правда подозреваю менее эффективно, хотя интересно было бы сравнить) в Akka с помощью Akka Cluster + Akka Persistence и ещё пары штук возможно.
P.S. Олег, ты чего на "вы", не первый день знакомы ;)
Эффективные надежные микросервисы
Выглядит как своя реализация идей, доступных в Akka. Рассматривали её?
Как собрать образ Oracle DB для Testcontainers
С reusable containers Ryuk не будет прибивать контейнеры которые помечены как reusable, в том и смысл :)
Как собрать образ Oracle DB для Testcontainers
Начиная с Testcontainers 1.12.3, мы добавили "reusable containers", что позволяет переиспользовать контейнер между сессиями тестов при локальной разработке.
Так что теперь не обязательно использовать другой тул :)
R2DBC Arabba-RELEASE — новый взгляд на реактивное программирование для SQL
За репорт — респект!
Про "мультитредовые тесты" — надеюсь тоже репортил.
По ссылке на TechEmpower (который я кстати не очень люблю, учитывая что он был создан чтобы показать какой их фреймворк быстрый и ни раз был замечен делающим некорректные бенчмарки для других) r2dbc не нашёл.
Опять же, стоит мерять производительность реальных реактивных сервисов (JDBC + Thread Pool vs R2DBC), где каждый вызов JDBC будет идти через context switch т.к. блокировать текущий реактивный поток нельзя.
В "песочнице" R2DBC vs JDBC показывает себя неплохо (особенно с MSSQL, кстати), а так же есть куда оптимизировать. В таких вещах обычно первым идёт "сделать чтобы работало" а потом уже "чтобы быстро".
R2DBC Arabba-RELEASE — новый взгляд на реактивное программирование для SQL
А не поделитесь ссылками чтобы подтвердить своё мнение? На открытые баг репорты, бенчмарки.
А то иначе выглядит как вброс ;)
R2DBC Arabba-RELEASE — новый взгляд на реактивное программирование для SQL
Конечно, конечно… нет :D
Файберы и корутины упрощают для юзера, а реактивщина — делает чтобы быстро было!
Одно другому не мешает ;)
ИМХО
файберывиртуальные потоки только улучшат adoption реактивных технологий — потому что можно будет не бояться "что-то там заблокировать", а всякиеflatMap
concatMap
превратятся в обычныйmap
.Из Groovy ушёл Cédric Champeau
Как опытный Jenkins-овод, могу заверить:
1) "Groovy не работают в некоторых местах" — это скорее бага, чем особенность, которую они так и не смогли побороть
2) "тратить часы чтобы понять как оно вообще собирается и кто кого зовет" — так же применимо к Jenkinsfile-ам, иногда даже ситуация гораздо хуже, чем в Gradle.
3) "структуру можно полностью переопределить" — это не совсем так. В Gradle действительно можно "пачкать" variable scope, но нельзя, например, переопределить "configurations {}" блок, в итоге имеем структурированность практически как в декларативном Jenkinsfile-е
4) "stages" в Jenkinsfile только если использовать декларативный подход, он не всегда подходит, приходится использовать императивный, и там ад и содомия похлеще Gradle файлов
Из Groovy ушёл Cédric Champeau
А ничего что Jenkinsfile это Groovy?:)
Строители против синтаксиса Java
Надо знать только этот класс, и на нём будут все методы.
Не совсем. Юзер просто использует
$DesiredUserType.Builder
и видит все поля, которые можно "настроить" с помощью билдера.Т.е. пользователь не ищет "а где же настроить pantonymic", он имеет тип, и видит какие параметры этого типа можно установить.
Строители против синтаксиса Java
Значительно упрощенный API благодаря этому.
Юзеру не надо знать о всех существующих билдерах, не надо знать в каком из них настаривается
foo
, а в каком —bar
(типичная проблема композиции).Строители против синтаксиса Java
Это уже не "наследование".
Строители против синтаксиса Java
1) дублирование объявлений полей
2) Да.
Строители против синтаксиса Java
Даже ваш великий Котлин не спасает от тонны ненужного синтаксиса здесь. Особенно когда таких полей десятки.
Строители против синтаксиса Java
по-моему в вашем примере кол-во "new" удваивается при добавлении нового наследника ;)
А когда пропертей десятки, то такой код начинает пугать. И ещё, у него есть один важный недостаток — при добавлении метода в базовый класс, он не попадает в наследников пока его вручную везде не добавят.
Строители против синтаксиса Java
Тогда это уже не называется "наследование"
Строители против синтаксиса Java
Рассматривали.
С таким очень сложно работать, нет нормального способа хранить состояние (например, коллекции открытых портов, или переменных окружения), ну и не очевидный способ создания через прокси и вот это вот всё (в PR кстати чуть по-другому это решили)
Строители против синтаксиса Java
ну, не решается, скорей просто убирает часть проблемы. Но проблема всё же остаётся, особенно когда на реальных примерах её погонять (прошли через это, был одним из вариантов API)
Строители против синтаксиса Java
Летали. Знаем.