NestJS, MongoDB, Mongoose, GraphQL - повторяю, описывая пользователя или любую модель - PullRequest
Новая
       29

NestJS, MongoDB, Mongoose, GraphQL - повторяю, описывая пользователя или любую модель

0 голосов
/ 11 февраля 2019

Редактирование: я реализовал ниже, опубликовал его в GitHub для аутентификации пользователя.

Редактирование на основе комментария: Может ли файл DTO быть заменен классами, которые генерирует @ nestjs / graphqlна основе типов GraphQL?Могу ли я создать приложение NestJS / MongoDB / Mongoose / GraphQL, сгенерировав эти классы, а затем расширив их для моей схемы MongoDB.Затем, после этого вопроса, приветствуются любые мнения о наилучшей практике, но будет принят ответ, отвечающий вышеизложенному.Ниже оригинальное сообщение:

Как лучше всего описать модель пользователя?Это определить типы graphQL и использовать его для генерации классов для замены файлов dto и импорта в Mongoose для схемы MongoDB?Ниже я объясню, что я делаю, и что может работать лучше.Количество файлов, которые я повторяю, кажется не масштабируемым.

Вот несколько способов описать одного и того же пользователя:

users.types.graphql - Типы GraphQL, которые содержат create userвходы, обновление пользовательских входов и т. д. Он содержит такие вещи, как: 

type Mutation {
  createUser(createUserInput: CreateUserInput): User
}

input CreateUserInput {
  username: String
  email: String
  password: String
}

type User {
  _id: String!
  username: String
  email: String
  password: String
}

user.interfaces.ts - Описывает тип пользователя, используемый схемой MongoDB и мой user.service.ts, который содержит: 

export interface IUser {
  email: string;
  password: string;
  username: string;
}

user.schema.ts - схема MongoDB.Описывает пользователя в Mongoose.Он также расширяет пользовательский интерфейс в user.interfaces.ts и Document для предоставления методов экземпляра для строгой проверки типов (я могу добавить .checkPassword к IUserDocument): 

export interface IUserDocument extends IUser, Document {
  checkPassword(
    password: string,
    callback: (error?: Error, same?: boolean) => any,
  ): void;
}
export const UserSchema: Schema = new Schema(....
UserSchema.pre<IUserDocument>('save', function(next) {
UserSchema.methods.checkPassword = function(....

create-user.dto.ts и все виды dto с для каждой операции.Они кажутся излишними в моем файле типов GraphQl с описанием входных данных выше.Вот dto: 

export class CreateUserDto {
  readonly email: string;
  readonly password: string;
  readonly username: string;
}

Мне интересно, как лучше всего иметь одну правдивую информацию для моих пользовательских моделей. Я думаю:

Использовать 

GraphQLModule.forRoot({
  definitions: {
    path: join(process.cwd(), 'src/graphql.classes.ts'),
    outputAs: 'class',
  },

И использовать это для моих интерфейсов и моих dto файлов, так как он выводит: 

export class CreateUserInput {
  username?: string;
  email?: string;
  password?: string;
}

export class User {
  _id: number;
  username?: string;
  email?: string;
  password?: string;
}

Будут ли тогда нужны dto файлы?Имеет ли значение, что они не только для чтения?Могу ли я автоматически разделить эти классы на свои соответствующие папки (пользователи в пользовательскую папку, продукты в папку продуктов)?

Я опубликую общедоступную ссылку на GitHub, когда закончу с печеньем NestJS, MongoDB,Passport-JWT, серверная часть GraphQL с аутентификацией пользователей, поэтому у людей есть ссылка (есть такая, которая использует DTO).

1 Ответ

0 голосов
/ 05 июля 2019

Я запутался в вашем вопросе из-за аналогичных проблем при настройке какого-либо API nest.js / graphQL / mongoose.Исходя из опыта laravel / REST / SQL, я был очень недоволен избыточностью и понятия не имею, как создать какой-то общий стандарт CRUD, где добавление новых ресурсов будет простым и быстрым, например, с использованием сценария узла для создания шаблонаи т. д. Таким образом, можно сосредоточиться на реализации «новых» функциональных возможностей вместо того, чтобы писать тонны кода для одного и того же материала.

Я взглянул на ваш проект GitHub, и, как мне кажется, вы уже оптимизировали этов некотором смысле (например, user.schema для mongoose и graphql)?Я начал использовать подход кода в отношении graphQL, но я думаю, что вы придерживаетесь подхода схемы сначала?Было бы очень интересно обменяться мыслями на эту тему, так как здесь или где-то еще не много информации о nest.js!

...