Using TypeGraphql to generate schemas instead of using gpl

[hatim-heffoudhi]

Hello,
It' will be a nice feature, if we can create a common model or just the model (input and types) in typescript class adding some decorators to generate schema, by using the library typegraphql

And with this you can share model between the API and the WEB part (in a module...)

@ObjectType()
class Recipe {
  @Field(type => ID)
  id: string;

  @Field()
  title: string;

  @Field({ nullable: true })
  description?: string;

  @Field()
  creationDate: Date;

  @Field(type => [String])
  ingredients: string[];
}

with this, we can avoid boilerplate code and some duplicates...
With typeGraphql we can add some logic code in our model (types), instead of

export const schema = gql`
  type Todo {
    id: Int!
    body: String!
    status: String!
  }
  type Query {
    todos: [Todo]
  }
  type Mutation {
    createTodo(body: String!): Todo
    updateTodoStatus(id: Int!, status: String!): Todo
    renameTodo(id: Int!, body: String!): Todo
  }
```

[guledali]

Those duplicates you mentioned causes a lot of pain a larger app,

you should have also mentioned this https://www.npmjs.com/package/typegraphql-prisma

Another concept would be having so called Dto (Data transfer object) and specifying length on a field. Here is an example

import { MinLength, MaxLength } from 'class-validator';

export class CreatePostInput {
  @MinLength(3)
  @MaxLength(50)
  title: string;
}

  @Mutation(returns => PostType)
  createPost(@Args('createPostInput') createPostInput: CreatePostInput)  {
    return this.postService.createPost(createPostInput);
  }

[hatim-heffoudhi]

yep, I know the concept of DTO , it's a pattern used in many languages to fix duplications, decoupled models, etc....
and the benefits of using DTO/class/model instead of GPL is to use it as a interface from front to back and vice versa, specify methods..... i used typegraphql is a framework inspired by typeorm, you can define your model, service, resolvers, generate documentation, maybe its a framework we can explore it in redwoodsjs, for that I'm ready to contribute it

[guledali]

Also lack of autocompletion and go-to-definition inside sdl can probably make it harder to scale as in long-term maintainability and also getting out-of-sync really quickly when the project grows, and I agree having code-first approach is much better, TypeScript all the way of through.

[jtoar]

I'll be sure to bring this up for discussion, but we've stuck to our sdl so far; here's Tom's response to "why doesn't redwood use something like nexus" in the forums: https://community.redwoodjs.com/t/anyone-playing-around-with-nexus-js/360/5.

That doesn't mean we can't provide types across sides. The TS experience is already getting a lot better with #2485.

Also lack of autocompletion and go-to-definition inside sdl can probably make it harder to scale as in long-term maintainability and also getting out-of-sync really quickly when the project grows

The RedwoodJS IDE handles this beautifully; granted, it doesn't right now (we're breaking it constantly as we're nearing a v1 rc, but as a rule, tooling comes last—after the project's defined).

[jtoar]

Now that we're post v1, something like this really doesn't seem like it's in the cards. Happy to discuss again if there's community interest but closing for now.