Ну они ведь бывают очень нетривиальными, если структура где-то поменялась, и надо данные перераскидать в новую схему.
Ещё бы обратную миграцию)

ну это адок, че сказать

)

Вот потому я и сделал отдельной функцией, запускаешь синхронизацию, запускаешь функцию поторая просидирует а дальше код, для дева для тестов самое оно. А на проде никаких рук... только миграции, с историей с откатами и т.д. и побольше бекапов)

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

Там же при инициализации передаешь список моделей

Так в том то и дело, если мне у меня 3 модели а синхронизировать я хочу только 2, вот тут беда. Пользоваться 3, а синхронизировать 2)

Мало ли чего ты захотел ))))

ну вот потому я и создал свой модуль для неста)

Ну блек Джек у тебя есть, но вот шлюх не вижу

Я вот думаю, может секцию с типо безопасностью запросов добавить, что б показать как легко это можно сделать в knex

Йоу, ребят, очень сильно запутался, когда юзать DTO, когда I? Чем они отличаются?

Вот так?

async signup(@Body() userModel: IUserSignupDTO): Promise<IUserSignup> {
  return null;
}

export interface IUserSignup {
  _id: string;
  nickname: string;
  firstName: string;
  lastName: string;
  photoURL: string;
  email: string;
  password: string;
  createdAt: number;
}

export class IUserSignupDTO {
  @ApiProperty({
    type: String
  })
  nickname: string;

  @ApiProperty({
    type: String
  })
  firstName: string;

  @ApiProperty({
    type: String
  })
  lastName: string;

  photoURL: string;

  @ApiProperty({
    type: String
  })
  email: string;

  @ApiProperty({
    type: String
  })
  password: string;

  createdAt: number;
}

DTO – при создании и изменении. Интерфейсы – при получении и других случаях

Интерфейс это контракт работы вообще, это контракт передачи данных, I можно нигде не ставить

Во, оч внятно, спасибо!

есть рекомендации по next + ssr для react? Ведь нода однопоточная, и есть что то асинхронно делаем это живет в одной ноде. И в таком случае в одном процессе может оказаться несколько пользователей и я случайно могу отдать не то =/

ох уж эти пихапишники, привыкли к глобальным пространствам)))

не, просто я думаю про IoC/DI и некоторые антипаттерны, получается лучше не использовать

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