Чтобы упростить разработку наверное.

какой именно?)

Эфир, Трон)

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

Многопоточность не для него нужна была.

а для какого БЧ?)

Ни для какого. Просто чтобы было.

Для отказоустойчивости

Привет. Каким способ можно задеплоить нест со статическим фронтом(вуе) на aws? Сначала нашел способ с помощью серверлесс + лямбда, но когда смог развернуть на офлайне понял что это бред - серв запускается на каждый запрос, а потом отрубается. Сейчас пытаюсь с помощью elastic beams, но что-то тоже не получается пока, есть гайды, все разные. Может быть у кого нибудь есть опыт в развёртке, или пример? Может быть нужно развернуть как то отдельно? Фронт в одном сервисе, бек в другом, но как тогда соединить вообще не понимаю.. мне кажется более лучшее решение было бы все таки разворачивать мой фронт на несте, без подключения ещё кучи сервисов авс. Буду признателен, если кто нибудь натолкнет на то, каким способом это решить

не использовать aws.

билд фронта заливай на S3, потом подключи CloudFront ( CDN ) для раздачи ибо с S3 раздавать - дорогой трафик
потом подключи Route53 для домена если хош всем этим делом с AWS управлять
для бекенда если тебе хватит одного сервера - создаешь EC2 инстанс и руками накатываешь шо тебе нужно там
если надо Load Balancing, если надо проще и не мучиться - Elastic Beanstalk

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

Спасибо! Понятно что мудохаться не хочется, но по мне так лучше разобраться с авс, где все что нужно есть, и в дальнейшем это очень пригодится
Пойду пытаться)

Ребята, привет! Есть тут сеньоры / мидлы , которые могут поконсультировать? Вопросы про дробление проекта при проектировании на микросервисы. Стэк: nest + mongo + postgre

Из моего опыта, проектирование микросервисов это больше организационная работа, чем техническая (закон Конвея, все такое). Микросервисы, которые пытались изначально проектировать по каким-то техническим критериям, потом все равно склеивались/разбивались по организационной структуре, которая их обслуживала, поэтому хз вообще насколько оправданно таким заниматься

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

Ребята, привет!  подскажите новичку так сказать 🙂
Я могу как то payload получать через DTO или как правильно создавать этот  payload чтобы реализовать DRYConcept

TokenPayload

Если знакомы с DDD и нет требований выделить и оптимизировать какой-то конкретный функционал, то, ИМХО, для начала хорошо разбивать по bounded context'ам. Это уменьшит количество запросов между сервисами,  да и если будет несколько команд,  то они чаще всего также в итоге и формируются.

Как в призме сделать deleteMany с include?