оно и в джаве норм делается. и в чем хочешь. Просто в скалах всяких можно много всяких других интересных вещей делать

Я только думал как это технически сделать, чтобы норм выглядело

ну Either же ?

или вот

так а в чем проблема, чето аля return Promise.all([ firstOp(request), secondOp(request), thirdOp(request, smthElse) ]).then(() => response.ok(), e => response.error(e))

ну Either же ?

Хех

У меня в рубях это зовется Result

и я до сих пор путаю (пишу Either) ?

ну не самая большая проблема)

По сравнению с руби - да, не большая :)

для джавы ведь есть vavr, там чего-то для описанной выше валидации не хватает разве?

http://gorodinski.com/blog/2012/05/19/validation-in-domain-driven-design-ddd/ В этой статье есть такой вывод: It is easier to duplicate validation logic than to keep it consistent across application layers. Согласны ли вы, на практике у вас так и есть или все наоборот?

не читая - согласен. дублировать реально проще.

не читая - согласен. дублировать реально проще.

+

И другие приключения в языках без статической типизации :|

IO всегда надо покрыть валидацией, а дальше уже нет "валидации", дальше уже бизнес-логика

Ты еще either верни Валидировать данные он собрался, ля

Юзерам нужно доверять!

Лучше вообще прям зашмвать в проекте шелл где-нибудь

Чтобы мало ли че, зашел - поправил

Лучше вообще прям зашмвать в проекте шелл где-нибудь

Пхпшники не поймут

не читая - согласен. дублировать реально проще.

Не читая, могу сказать, что скорее всего он под дублированием понимает случайное совпадение, а не полноценное дублирование)

Более подробно выскажусь после прочтения)

Если кратко: Он валидирует на UI (он может быть как в браузере, так и на бекенде, так и на desktop). А потом "валидация" происходит еще раз, при создании доменного объекта. Хотя скорее это инвариант а не валидация, но тут есть разногласия что это.

Юзерам нужно доверять!

Как ты прав. Без доверия жить нельзя

https://habr.com/company/avito/blog/426101/

отгадай по названию о чём будет идти речь)

я только так и не понял, почему они саги юзают именно в контексте транзакций уровня базы данных. Оно, конечно, может эмулировать одну из буковок, но это больше побочный эффект, как по мне

https://guides.hexlet.io/check-list-of-engineering-practices/

https://guides.hexlet.io/check-list-of-engineering-practices/

thx

Насколько упоротая идея загнаться идемподентностью, в скажем рест сервисе. Убираем полностью POST запросы, создание и модификация ресурса через PUT. Генерируется id для нового ресурса (uuid например) на строне клиента. Далее, при запросе, если нет объекта создаем его, если есть - апдейтим.

Насколько упоротая идея загнаться идемподентностью, в скажем рест сервисе. Убираем полностью POST запросы, создание и модификация ресурса через PUT. Генерируется id для нового ресурса (uuid например) на строне клиента. Далее, при запросе, если нет объекта создаем его, если есть - апдейтим.

вполне нормальная идея, но скорее всего найдутся ситуации когда все это будет не дешево.

например можно было сделать 1 запрос а приходится делать 4 хитрых но зато ретраи можно делать сколько хочешь

Вот хочу прОщупать эти кейсы. Со связями ресурса например.

но ничего плохого в таких вещах нет, наоборот, если есть возможность

> Далее, при запросе, если нет объекта создаем его, если есть - апдейтим это называется upsert

генеришь id ?

https://yt3.ggpht.com/a-/AN66SAxOlIM2f48DSFSeQZ-SuhYa8e6eKoX0SoVwow=s900-mo-c-c0xffffffff-rj-k-no #распределенный_монолит

Насколько упоротая идея загнаться идемподентностью, в скажем рест сервисе. Убираем полностью POST запросы, создание и модификация ресурса через PUT. Генерируется id для нового ресурса (uuid например) на строне клиента. Далее, при запросе, если нет объекта создаем его, если есть - апдейтим.

Насколько упоротая идея загнаться идемподентностью, в скажем рест сервисе. Убираем полностью POST запросы, создание и модификация ресурса через PUT. Генерируется id для нового ресурса (uuid например) на строне клиента. Далее, при запросе, если нет объекта создаем его, если есть - апдейтим.

идемпотентность эт хорошо

Насколько упоротая идея загнаться идемподентностью, в скажем рест сервисе. Убираем полностью POST запросы, создание и модификация ресурса через PUT. Генерируется id для нового ресурса (uuid например) на строне клиента. Далее, при запросе, если нет объекта создаем его, если есть - апдейтим.

Прочитай определение идемпотентности, то что ты собираешься делать чет не очень смахивает на идемпотентность

самый простой пример идемпотентности это q.state() // {postId: 123, likes: 0} const ev1 = { type: “like”, payload: {user: user, postId: 123} } const ev2 = { type: “like”, payload: {user: user, postId: 123} } q.processEvents(ev1).processEvents(ev2) // {postId: 123, likes: 1}

x * x = x короче

если ты что-то обновляешь, то это уже нарушает саму суть что ты можешь что-то несколько раз применить и получить один и тот же результат

если ты что-то обновляешь, то это уже нарушает саму суть что ты можешь что-то несколько раз применить и получить один и тот же результат

Ну не совсем

Точное определение описывает скорее иную форму f(x) === f(f(x))

И она уже не конфликтует с обновлением

и структура данных определяет равенство как ей захочется?

и структура данных определяет равенство как ей захочется?

Здесь говорится лишь о том, что результат выполнения функции не зависит от количества вызовов, свойства объекта вообще не требуются)

с чего бы это вот есть у тебя например операция multiplyOneByX(x), операция будет идемпотентой только в том случае если туда передавать единицу т.е сама операция обладает таким свойством только на одном значении из всех возможных Если у тебя есть массив, то операция конкатенации идемпотентна только на пустых массивах и это же операция полагается на свойство структуры данных(в данном случае наличия нейтрального элемента) Мне сейчас сложно представить где в энтерпрайз практике ты бы реально захотел просто делать f(x) === f(f(x)) везде где только можно, это же имеет смысл только в некоторых случаях для удобства

хотя щяс сообразил что первый пример не верный, но энивей