😊 все нормально, мы в тематику офтопа перешли, точнее я )

Там качели карусели, уже пробовал)

У них очень слабая поддержка версии винды

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

В экспрессе я это делал через res.status.... но допустима ли подобная практика для Nest?

Он сам все за тебя делает. На посты статус 201, на гет 200. Возвращает то что ты возвращаешь из роута через return

Этот декоратор задает базовый код ответа, который будет когда все ок, но если у тебя что-то там не так, тогда делай так throw new NotFoundException('тут можно сообщение кидать') - если нет класс для кода ответа который тебе нужен тогда делай throw new HttpException(тут код)

Ля, спасибо всем, теперь все понятно

Все что мы сказали есть в доке, просто чутка внимательнее нужно ее читать. А лучше вообще два раза на каждую категорию

У неста очень качественная дока на мой взгляд

Прочитал доку, прочитал еще раз, прочитал 3 раз но уже смотрим соур код. Тогда вообще многие моменты станут понятными. И конечно же по чаше использовать CTRL + Click по методам, что бы смотреть какие параметр могут там они получать.

ребят, всем привет. подскажите, пожалуйста, кто как использует репозитории typeorm? пишется ли в них какая-то логика, относящаяся к сущности? например, проверка пароля для логина или signup, где мы берем данные из dto и шифруем пароль перед сохранением сущности могут быть реализованы в репозитории или это все должно быть исключительно в сервисах а репозиторий только для операций типа find/create/update и т.д.? не могу понять для себя предназначение этой штуки

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

окей, а что тогда должно быть там? тогда по сути в 90% случаев мы просто его создаем ради того чтоб получить методы для работы с сущностью и будут они выглядеть примерно вот так?
@EntityRepository(User)
export class UserRepository extends Repository<User> {}

а всеми методами мы уже пользуемся внутри сервисов?

Да, создается репозиторий для того что бы ORM понимала что в этом Entity будет и что бы она позволяла вам использовать простые find() save() а так же мапить raw ответ базы на башу модель.

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

Угусь, можно еще докидывать специфичные методы (типа findAllFailedOrInProgress) для скрытия деталей получения данных (не бизнес-правил, а именно логики получения данных), чтобы в бизнес-логике всё читалось пятиклассником

ага, имеет смысл

Просто паттерн другой)

спасибо за ответы)

Привет,подскажите как в запрос примерно такого типа добавить условие не?(NOT)