Type-graphql: Differences with typegql + Nest.js integration

[tonyxiao]

What's the difference between this library and typegql? Can you provide a bit more context?

[MichalLytek]

Basically, typegql is a smaller, simpler library for creating schema from classes where TypeGraphQL aims to have more features to speed up development of GraphQL API.

AFAIK, typegql lacks support for interfaces and subscriptions, it also has less powerfull hooks/middlewares API, not typesafe unions, no field resolvers in resolver classes (with dependency injection) and no way to define args as a class (class-validator case) - the rest is basically 90% the same.

And of course TypeGraphQL was created earlier, it's more mature and more popular! 😎
https://seladb.github.io/StarTrack-js/?u=19majkel94&r=type-graphql&u=prismake&r=typegql

[tonyxiao]

Haha, I wish we could pool together resources and just make one amazingly good and the standard for GraphQL development in TypeScript. In particular, if we can integrate / replace the default GraphQL recommendation in nestjs it can lead to a lot more people being onboard.

[MichalLytek]

I wish we could pool together resources and just make one amazingly good and the standard for GraphQL development in TypeScript.

I've proposed joining forces a long time ago but we have separate visions 😉
https://github.com/prismake/typegql/issues/22#issuecomment-387180953

In particular, if we can integrate / replace the default GraphQL recommendation in nestjs it can lead to a lot more people being onboard.

There's already an integration done by the community 🍾
https://github.com/MagnusCloudCorp/nestjs-type-graphql

And I've seen discussion with Kamil - he said that he treats GraphQL SDL as a first class citizen and he don't think that replacing it with class/decorators abstraction is a good idea.
https://twitter.com/kammysliwiec/status/1001773640428421120

Maybe in the feature when I split the repo to monorepo with multiple packages/plugins, I would be able to better integrate with nest and it's guard/interceptors features, providing only schema generation part from classes and decorators 😉

[tonyxiao]

Got it. Glad to have the additional context. I think making it easier to use nestjs with type-graphql can have a good impact on # of adopters.

Something to note in my own integration, the IOC container types were not compatible

Nest ioc container

type-graphql container type

compiler error when trying to put them together.

I was able to cast to any and have it work at runtime. However i'm not sure if i'm missing anything. How is the IOS container suppose to use resolver data in particular?

[tonyxiao]

Just saw Kamil's tweet

I believe that GraphQL schemas are supposed to be language-agnostic. Hence, we might share type definitions regardless of the platform used underneath. That's why Nest doesn't dynamically generate them and treats .graphql files as 'first-class citizens' :)

Totally get that, and like you said there's no reason we can't provide schema generation part from classes and decorators as an alternative for people whose usecase match that. And yes better integrate with nest and it's guard/interceptors features would be awesome.

Nestjs seems to have a habit of building things itself though. I wonder why it doesn't use something like typedi for dependency injection and had to build its own one in house. Do you know?

Have you seen the new typescript 3 projects feature? Might just be the kick needed to switch to monorepo.

[MichalLytek]

TypeGraphQL calls the get method with resolverData as a second parameter while NestJS expects options object.

So you need to create a adapter:

export function convertNestContainer(app: INestAplicationContext, options?: { strict?: boolean }) {
  return {
    get(tokenOrClass: any) {
      return app.get(tokenOrClass, options);
    }
  }
}

Maybe you should create a PR in nestjs-type-graphql repository with that fix 😉

[tonyxiao]

Ah, ok. Is the IOC container suppose to do something special with the resolverData? In the example you have above it's rather just discarded.

[MichalLytek]

I wonder why it doesn't use something like typedi for dependency injection and had to build its own one in house. Do you know?

It's basically routing-controllers wrapped in Angular modules 😆 So it uses injection-js, the same as old Angular 2-4.

Have you seen the new typescript 3 projects feature? Might just be the kick needed to switch to monorepo.

Lerna is good for monorepo too - the only blocker now is my graduation work. I have to finish it before I start implementing new features.

Is the IOC container suppose to do something special with the resolverData? In the example you have above it's rather just discarded.

Basically it's used for scoped container feature:
https://19majkel94.github.io/type-graphql/docs/dependency-injection.html#scoped-containers
See usage of resolver data in PR https://github.com/19majkel94/type-graphql/pull/113

[tonyxiao]

Except it seems to use neither under the hood, but rather its own thing that have super similar design. Which is confusing to me. Does nestjs want to create a whole framework and control vertically most aspects of it?

Didn't know you are still in school! That's awesome.

[MichalLytek]

Does nestjs want to create a whole framework and control vertically most aspects of it?

That's the idea of framework. I prefer to give users freedom, that's why you have useContainer functionality.

Didn't know you are still in school! That's awesome.

School 😆 I have Bachelor’s degree and maybe next month I will have Master's degree 😉

[tonyxiao]

@19majkel94 what are your thoughts on the Before and After decorators? In particular, they enable Object aware authorization (eg. only I can see my email address).

What's your recommendation for doing those inside type-graphql?

[MichalLytek]

Just use the middlewares feature 😉
https://19majkel94.github.io/type-graphql/docs/middlewares.html#custom-decorators

[tonyxiao]

whoa how did I miss that?! Sick!

[MichalLytek]

Closing this issue for housekeeping purposes 😉