PS
серьезно?
не обязательно настолько категорично относиться.
Size: a a a
2021 March 05
AK
Просто сейчас не понятно кто именно виновен в падении
VL
команда вполне себе может возвращать результат операции
по классике
interface Handler{
handle():void
}
interface Handler{
handle():void
}
NP
но вообще, если прям очень надо, то можно и спаковать. но так не принято
Да кстати может быть и принято
VL
серьезно?
если серьезно, то ивент обратно хуярнуть
AS
серьезно?
traceId или taskId, а как ещё сопоставить запрос с ответом?
NP
Вебпак билды сильно меньше полной директории с node_modules, удобно для разворачивания в докере без необходимости держать в контейнере полгига зависимостей
PS
по классике
interface Handler{
handle():void
}
interface Handler{
handle():void
}
ну и ради чего так себя ограничивать?
"команда" не должна заниматься работой "запросов". вот и все.
"команда" не должна заниматься работой "запросов". вот и все.
A
ну да, у нас архитектурные вопросы последнее время идут и достаточно интересные, вывод - вы ничего в них не понимаете либо вы слишком круты для этого
я склонен к 1 варианту
я склонен к 1 варианту
Простите, это какие архитектурные вопросы?) Вы про теоретические основы, типа вот этого, что идет сейчас?)
N
если серьезно, то ивент обратно хуярнуть
типа там нет императивного подхода а-ля:
const entity = await createSomeEntity();
await processSomeOtherShit(entity);
await doOtherStuff();
там отправил ивент, и независимо от него пришел в ответку ивент и дальше на него ответ, потом второй ивент и т.д.?
const entity = await createSomeEntity();
await processSomeOtherShit(entity);
await doOtherStuff();
там отправил ивент, и независимо от него пришел в ответку ивент и дальше на него ответ, потом второй ивент и т.д.?
N
т.е. обработчики ивентов делают только 1 штуку какую то
NP
Adv0cat
я серьйозно, вы видели тут умные вопросы?)) я что не зайду, то или про jwt vs session, то бля где хранить данные юзера 😏
Юзера в локалсторадже надо хранить
N
и если надо что то еще то в ответку прийдет от другого сервиса
АП
а у меня тоже довольно поверхностное представление.
якобы такое разделение полезно если подсистема для чтения (запросы) не справляется с нагрузками. и тогда можно для нее не грузить всё ооп, не создавать всяких агрегатов и сущностей, а делать просто оптимизированные sql запросы.
якобы такое разделение полезно если подсистема для чтения (запросы) не справляется с нагрузками. и тогда можно для нее не грузить всё ооп, не создавать всяких агрегатов и сущностей, а делать просто оптимизированные sql запросы.
Или наоборот, "подсистема" записи не справляется с нагрузками
Тогда можно разбивать подготовку и сохранение данных на этапы, а первым будет как раз cqrs
Тогда можно разбивать подготовку и сохранение данных на этапы, а первым будет как раз cqrs
NP
Юзера в локалсторадже надо хранить
Владиленчик Минин так завещал.
PS
по классике
interface Handler{
handle():void
}
interface Handler{
handle():void
}
а если бд ошибку вернула, то что делать? исключение кидать? так это мы, получается, уже не только void возвращаем. какая разница, что оно возвращается через механизм исключений. ай-ай-ай, нарушение контракта
A
Юзера в локалсторадже надо хранить
та чо уж юзера, всю базу данных в jwt 😏
VL
бля
не могу нормально сформулировать но у нас мс системы обычно АСИНХРОННЫЕ ( не промисы ), мы общаемся ивентами и сообщениями и редко ждем ответы ибо тогда мы связываемся по времени
не могу нормально сформулировать но у нас мс системы обычно АСИНХРОННЫЕ ( не промисы ), мы общаемся ивентами и сообщениями и редко ждем ответы ибо тогда мы связываемся по времени
АП
Но если их будет 50 в одном проэкте то голова лопнет, проще будет все в одном сделатт
В одном из проектов на данный момент 70 (может и больше) микросервисов, пока ничего не лопнуло 🤷♂
NP
Adv0cat
та чо уж юзера, всю базу данных в jwt 😏
А вы тоже его курс по ноде заканчивали, как я вижу?