Я работаю в проекте https://gmonit.ru/ Мы делаем Observability платформу. И поддерживаем оригинальные агенты NewRelic APM. Интересно - пишите мне или по контактам на сайте - сделаем демо.
Если так смотреть, то все еще проще, эластик сам умеет оптимистические блокировки.
Возможно вы просто не сталкивались с подобными проблемами.
У нас очень много дублей. Оптимистические блокировки никак это не исправят, все равно нужно ходить в эластик/бд.
Предположим, пришла задача с id = 1. Пока она лежит в очереди, пришло еще с десяток задач с id = 1. Все кроме последней задачи протухли и обрабатывать их уже не нужно. Опять таки оптимистическая блокировка не поможет.
В браузере или nodejs есть единственный поток/процесс. Да, тяжелая математика его заблокирует. Но ввод вывод там асинхронный. На основе эффектов можно делать async/await только без цветных функций. Например передавать в map или reduce функцию с эффектом, что нельзя сейчас сделать.
Могу предложить такую метафору.
У вас есть код с эффектами. Этот код чистый, т.е. сам по себе он не взаимодействует с внешним миром.
Чтобы выполнить этот код нужен интерпретатор эффектов. И уже этот интерпретатор взаимодействует с внешним миром.
Этот интерпретатор вполне может использовать event loop вместо зеленых потоков.
Т.е. код с эффектами ни синхронный ни ассинхронный, это зависит от интерпретатора.
Или интерпретатор может идти по заранее подготовленному списку эффектв и их результатов — коэффектов. Таким образом мы можем проверить работу нашего кода.
Или "отмотать" код назад.
Или перенести частично исполненный код на другую машину/платформу, перенеся результаты уже исполненных эффектов и имея совместимый код на обеих машинах.
Тут речь о том, что у вас есть файл, разделяемая библиотека, микросервис и т.п. и должна быть возможность расширить его поведение без редактирования, перекомпиляции. А как именно это будет сделано — не особо важно. Можно через dependency injection, monkey patching и т.п.
Именно так, врядли кто-то сделает. Но это может всплыть, например, при клонировании.
Хибер правильно ругается. Далее я показываю пример с валидатором, что бы он тоже ругался.
Так никто серебряную пулю не обещает.
Если проект не развивается, хорошей идеей будет впилить костыль.
Если проект активно развивается, рефакторинг будет полезен.
Если отправка письма — это абстракция, и нужно изменить способ с smtp на mailchimp, то меняется только реализация. Даже не нужно перекомпилировать модуль с бизнес логикой.
Если изначально не нужна была скрытая копия, а теперь нужна — то это изменени бизнес логики. И требуется ее изменение и перекомпиляция модуля.
Конечно, интерактор может использовать несколько Сущностей, Служб.
Может не совсем удачная, но аналогия.
Интерактор — это как целая программа, бинарник. Она, как и другие, может использовать разделяемые библиотки. Пользователь может объединять их с момощью перенаправления потоков ввода-вывода.
Use Case не могут вызывать друг-друга.
При взгляде на код сценария мы должны видеть все его шаги.
Никто не запрещает выносить общий код в службы(service).
Речь идет о системе по модели запрос-ответ.
Интерактор — нечто, что обрабатывает некое событие.
Например, запрос пользователя или сообщение от сторонней системы.
В этом контесте интеракторы не общаются между собой напрямую.
Естественно, что пользователь может передать данные от одного интерактора другому.
Да, итеракторы не вызавают друг-друга, но могут разделять логику через сервисы.
Смотря для каких целей. И если есть поддержка языков.
Гонять данные в/из браузера — отлично.
Между системами — есть поддержка множества типов, можно добавить свои,
передал дату-время — получил дату-время.
Я работаю в проекте https://gmonit.ru/
Мы делаем Observability платформу. И поддерживаем оригинальные агенты NewRelic APM.
Интересно - пишите мне или по контактам на сайте - сделаем демо.
https://github.com/tonsky/Universal-Layout
Среди прочего lowkiq делает это.
Если так смотреть, то все еще проще, эластик сам умеет оптимистические блокировки.
Возможно вы просто не сталкивались с подобными проблемами.
У нас очень много дублей. Оптимистические блокировки никак это не исправят, все равно нужно ходить в эластик/бд.
Предположим, пришла задача с id = 1. Пока она лежит в очереди, пришло еще с десяток задач с id = 1. Все кроме последней задачи протухли и обрабатывать их уже не нужно. Опять таки оптимистическая блокировка не поможет.
https://youtu.be/TFCLaZr6vxY?t=11622 вот тут cto из ecwid рассказывают почему не взяли kafka, а написали сами. Мотивы схожие.
UPD: проект доступен под двойной LGPL or EULA лицензией.
del
В браузере или nodejs есть единственный поток/процесс. Да, тяжелая математика его заблокирует. Но ввод вывод там асинхронный. На основе эффектов можно делать async/await только без цветных функций. Например передавать в map или reduce функцию с эффектом, что нельзя сейчас сделать.
Могу предложить такую метафору.
У вас есть код с эффектами. Этот код чистый, т.е. сам по себе он не взаимодействует с внешним миром.
Чтобы выполнить этот код нужен интерпретатор эффектов. И уже этот интерпретатор взаимодействует с внешним миром.
Этот интерпретатор вполне может использовать event loop вместо зеленых потоков.
Т.е. код с эффектами ни синхронный ни ассинхронный, это зависит от интерпретатора.
Или интерпретатор может идти по заранее подготовленному списку эффектв и их результатов — коэффектов. Таким образом мы можем проверить работу нашего кода.
Или "отмотать" код назад.
Или перенести частично исполненный код на другую машину/платформу, перенеся результаты уже исполненных эффектов и имея совместимый код на обеих машинах.
modification — это про изменение артефакта, файла, а не про изменение поведения.
Тут речь о том, что у вас есть файл, разделяемая библиотека, микросервис и т.п. и должна быть возможность расширить его поведение без редактирования, перекомпиляции. А как именно это будет сделано — не особо важно. Можно через dependency injection, monkey patching и т.п.
Возможно будет интересно: https://github.com/tonsky/datascript
Там есть js api.
Именно так, врядли кто-то сделает. Но это может всплыть, например, при клонировании.
Хибер правильно ругается. Далее я показываю пример с валидатором, что бы он тоже ругался.
Так никто серебряную пулю не обещает.
Если проект не развивается, хорошей идеей будет впилить костыль.
Если проект активно развивается, рефакторинг будет полезен.
Абстракции имеют цену.
Если отправка письма — это абстракция, и нужно изменить способ с smtp на mailchimp, то меняется только реализация. Даже не нужно перекомпилировать модуль с бизнес логикой.
Если изначально не нужна была скрытая копия, а теперь нужна — то это изменени бизнес логики. И требуется ее изменение и перекомпиляция модуля.
Конечно выесняется, мы еще не научились предсказывать будущее.
Ты ожидал чего-то другого? =)
Конечно, интерактор может использовать несколько Сущностей, Служб.
Может не совсем удачная, но аналогия.
Интерактор — это как целая программа, бинарник. Она, как и другие, может использовать разделяемые библиотки. Пользователь может объединять их с момощью перенаправления потоков ввода-вывода.
Если остались вопросы, то лучше уже в личку.
Полная цитата:
Речь идет о системе по модели запрос-ответ.
Интерактор — нечто, что обрабатывает некое событие.
Например, запрос пользователя или сообщение от сторонней системы.
В этом контесте интеракторы не общаются между собой напрямую.
Естественно, что пользователь может передать данные от одного интерактора другому.
Да, итеракторы не вызавают друг-друга, но могут разделять логику через сервисы.
Буду рад, если посмотрите мою книгу на эту же тему и пототип.
Смотря для каких целей. И если есть поддержка языков.
Гонять данные в/из браузера — отлично.
Между системами — есть поддержка множества типов, можно добавить свои,
передал дату-время — получил дату-время.
А в чем вопрос?
https://github.com/cognitect/transit-format