Type-graphql: Using only typedefs, not resolvers

[BramKaashoek]

I would like to use only the typeDef generating capabilities of this library without using the resolvers, since I prefer the apollo-style resolvers. https://github.com/19majkel94/type-graphql/issues/222 makes me think it should be possible, but I could not find the way to do it in the documentation. Could you point me to which function to use?

As far as I can see, the buildTypeDefsAndResolvers function as described in https://github.com/19majkel94/type-graphql/pull/233 still requires me to write (minimal) resolvers?

Is there a function such as buildTypeDefs where I could pass in an array of my ObjectType/InputType classes to generate typeDefs?

[MichalLytek]

TypeGraphQL is all focused on resolvers and runtime improvements. Using it only for object and input typedefs is like driving your car without shifting the gears.

You can use simple code generator that will read your interfaces/classes and produce the typedefs SDL or maybe even try the reflection PoC:
https://github.com/19majkel94/typegraphql-reflection-poc

[BramKaashoek]

Thanks for the quick response.

https://github.com/19majkel94/typegraphql-reflection-poc looks like an interesting start.
Is it MIT licensed?

[BramKaashoek]

I wrote a small package to fill this need:
https://www.npmjs.com/package/typescript-typedefs

[MichalLytek]

I am reviving this feature as it might be handy to provide a step-by-step migration path and make use of the enhanced reflection plugin 💪

[syffs]

@BramKaashoek this seems nice, but it'd be great to handle @InterfaceType() to allow usage of typescript inheritence. What do you think ?

@19majkel94 this feature seems vital, there are plenty of scenarios which requires to work on typeDefs first without considering resolvers.. Is this complex to implement ?

[BramKaashoek]

@BramKaashoek this seems nice, but it'd be great to handle @InterfaceType() to allow usage of typescript inheritence. What do you think ?

You're completely right, I'll add that.

Edit: Added in version 0.1.9 https://www.npmjs.com/package/typescript-typedefs

[MichalLytek]

Is this complex to implement ?

Yes, it's a requirement of graphql-js to have at least one query to build the schema.

I would have to rewrite the core to just do decorators/reflection -> metadata -> schema string magic - will do in some time in the future with a more modular codebase 😉

[syffs]

@BramKaashoek all things considered, this'd be perfect with circular references out of the box ! The workaround is really not convenient...

Any idea on how to work around this ? I'm not aware of the root cause: could you please ellaborate ? Would a PR in reflect-metadata help ? Have you considered using an alternative (for example, this one is much lighter on paper)?

[BramKaashoek]

@syffs After doing some more looking around I found forward-ref as used by Angular, this might be a workaround. I'll look into it.

[syffs]

@BramKaashoek this might help, there's a suggestion on the related issue on typescript repo

[syffs]

@BramKaashoek good job, it's much more convenient with forwrad-ref !

Edit: Added in version 0.1.9 https://www.npmjs.com/package/typescript-typedefs

A suggestion about Interface and inheritence, this might make sense to automatically cascade fields from extended types / interfaces, or you end up with redundant Field, as below with author:

@Interface()
class Book {
  @Field()
  author: string;
}

// option 1 for implementing
@Type()
class CourseBook extends Book {
  @Field()
  author: string;

  @Field()
  course: string;
}

what do you think ?

[BramKaashoek]

A suggestion about Interface and inheritence, this might make sense to automatically cascade fields from extended types / interfaces, or you end up with redundant Field, as below with author:

This is what I was initially hoping to do, but sadly this is not possible due to how decorators work.

Let's take further discussion over to https://github.com/BramKaashoek/typescript-typedefs so that we don't bother Majkel as much :).