Type-graphql: Integration with Nest

[stevefan1999-personal]

Owner note

Scroll to typegraphql-nestjs package info ⬇️

Original post

I was wondering if there could be more support for Nest.js, in particular, integration with an authorization endpoint is needed. Right now, I'm using this NPM package + TypeORM, following the sample, so far so good but unfortunately the source was nowhere to be found, and so I have to workaround my auth checker which required me to pass the database module into the context but it is very dangerous. So what about an official extension of TypeGraphQL to Nest.JS? This would make it easier to write universal services.

[Salimlou]

HI @stevefan1999 ,

I am the author of that package, and here is the source https://github.com/MagnusCloudCorp/nestjs-type-graphql,

But it's really really basic integration I made for a small project, just a matter to respect NestJs lifecycle.

You can easily put the same code inside your app, so you have full control.

If you have any question!

[MichalLytek]

The goal of TypeGraphQL integration with Nest is to create a replacement/substitute for the GraphQL (Apollo) module for Nest, so all the Nest features like pipes or guards would work. This requires a lot of changes in TypeGraphQL core so it will be done later 😞

[kamilmysliwiec]

Would love to see it! ❤️

[Sacro]

I have this working without needing anything fancy

import { Injectable, Logger } from '@nestjs/common';
import { GqlOptionsFactory, GqlModuleOptions } from '@nestjs/graphql';
import { buildSchema } from 'type-graphql';

@Injectable()
export class GraphqlConfigService implements GqlOptionsFactory {
  async createGqlOptions(): Promise<GqlModuleOptions> {
    const schema = await buildSchema({
      resolvers: [__dirname + '../**/*.resolver.ts'],
    });

    return {
      debug: true,
      playground: true,
      schema,
    };
  }
}

And then in the app.module...

  imports: [
    GraphQLModule.forRootAsync({
      useClass: GraphqlConfigService,
    }),
  ],

[stevefan1999-personal]

@Sacro Do you have injects available for TGQL resolvers in runtime?

[Sacro]

I'm not sure I follow.

My current repo is at https://gitlab.benwoodward.me.uk/pokedex/backend

[stevefan1999-personal]

@Sacro In this case, you aren't using NestJS injections at all in resolvers far as I see, you also used Active Record pattern so you evaded the need for a repository. Unfortunately, I was indeed using AR pattern (with @nestjs/typeorm package) and some other providers so Injectable is definitely needed.

But the problem is, NestJS doesn't have a global container, it is re-entrant-able, so instead, the container is attached by an instance context by design.

[caseyduquettesc]

@stevefan1999-personal Injecting repositories seems to work fine for me when I build off @Sacro's awesome integration work. Here is one of my resolvers that I moved from @nestjs/graphql to type-graphql along with the original statements.

item.resolvers.ts

// import { Resolver, Query } from '@nestjs/graphql';
import { Resolver, Query } from 'type-graphql';

import { Item } from './item.entity';
import { ItemService } from './item.service';

// @Resolver('Item')
@Resolver(_of => Item)
export class ItemsResolvers {
  constructor(private readonly itemsService: ItemService) {}

  // @Query()
  @Query(_returns => [Item])
  public async getItems(): Promise<Item[]> {
    return this.itemsService.findAll();
  }
}

item.service.ts

import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';

import { Item } from './item.entity';

@Injectable()
export class ItemService {
  constructor(@InjectRepository(Item) private readonly itemRepository: Repository<Item>) {}

  public async findAll(): Promise<Item[]> {
    return this.itemRepository.find();
  }
}

[kamilmysliwiec]

I just realized that integration could be fairly easy. I'll provide a POC once I find some time :)

[christopherdupont]

I just realized that integration could be fairly easy. I'll provide a POC once I find some time :)

Hello Kamil, do you have any news about this POC ? I'm trying to find the best integration method for type-graphql and Nest.js.

[anodynos]

Hey @kamilmysliwiec I found type-graphql this past weekend, which I spend looking at many possible graphql solutions (from prisma to postgraphile to type-graphql). My opinion, it rocks! Just like NestJS, you can build anything :-) I think it's the most mature and feature complete library out there, and it will be AWESOME if it works smoothly with Nest - we can't wait for nest/type-graphql ;-)

So, I've been trying a couple of days to make them work and eventually they did, but with quite a few hacks, for example:

The type-graphql @Resolver classes are injected their service props fine initially, but then type-graphql creates it's own instance of the resolver and it is using it. Of course, it misses to DI the new instance, so all injections are lost.

So I had to hack it like:

let service: TheService;
@Resolver()
export class TheResolver {  
  constructor(private _service: TheService) {
    if (_service) service = _service; // workaround for DI 
  }
  @Query(ret => Them)
  getEm() { return service.getEm(); }
}

but its not nice or scalable etc.

So if we can make this integration happen, it will be really awesome!!!

[christopherdupont]

Hey @anodynos, you can look at this working solution :

_src/app/app.module.ts_

import * as path from 'path';

import { APP_INTERCEPTOR } from '@nestjs/core';
import { Module, CacheModule, CacheInterceptor } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';
import { GraphQLModule } from '@nestjs/graphql';
import { ConfigModule } from 'nestjs-config';

import { TypeOrmConfigService } from './typeorm.config.service';
import { GraphqlConfigService } from './graphql.config.service';

import { PaysModule } from 'pays/pays.module';

@Module({
  imports: [
    ConfigModule.load(path.resolve(__dirname, 'config/**/*.{ts,js}')),
    CacheModule.register(),
    TypeOrmModule.forRootAsync({ useClass: TypeOrmConfigService }),
    GraphQLModule.forRootAsync({ useClass: GraphqlConfigService }),
    PaysModule,
  ],
  providers: [
    {
      provide: APP_INTERCEPTOR,
      useClass: CacheInterceptor,
    },
  ],
})
export class AppModule {
}

_src/app/graphql.config.service.ts_

import { Injectable } from '@nestjs/common';
import { GqlOptionsFactory, GqlModuleOptions } from '@nestjs/graphql';
import { ConfigService } from 'nestjs-config';
import { useContainer, buildSchema } from 'type-graphql';

@Injectable()
export class GraphqlConfigService implements GqlOptionsFactory {
  constructor(private readonly config: ConfigService) { }

  setContainer(container: any) {
    useContainer(container);
  }

  async createGqlOptions(): Promise<GqlModuleOptions> {
    const schema = await buildSchema({
      resolvers: [ __dirname + '../**/*.resolver.ts' ],
    });

    return {
      debug: this.config._isDev(),
      playground: this.config._isDev(),
      schema,
    };
  }
}

_src/pays/pays.service.ts_

import { Injectable } from '@nestjs/common';

import { Pays } from './pays.entity';

@Injectable()
export class PaysService {
 async findAll(): Promise<Pays[]> {
    return Pays.find();
  }
}

_src/pays/pays.resolver.ts_

import { Injectable } from '@nestjs/common';
import { Resolver, Query, Arg, Int } from 'type-graphql';

import { Pays } from './pays.entity';
import { PaysService } from './pays.service';

@Resolver(of => Pays)
export class PaysResolver {
  constructor(private readonly paysService: PaysService) { }

  @Query(returns => [Pays])
  async pays(): Promise<Pays[]> {
    return this.paysService.findAll();
  }
}

_src/main.ts_

// Nest App
const app = await NestFactory.create(AppModule, server);
const graphQlConfigService = app.get(GraphqlConfigService);
graphQlConfigService.setContainer(app);

[caseyduquettesc]

That method still won't use any guards or interceptors that you have setup in NestJS. The only way I've gotten requests to go through those is by using Nest's @Resolver decorator, which can't be used on the same class as type-graphql's @Resolver decorator.

[anodynos]

Thank you Christopher @christopherdupont - I had a similar setup at some point, didn't work :-(
Does yours work without the problem/workaround I described above?

Basicaly I took code / ideas from @Sacro https://gitlab.benwoodward.me.uk/pokedex/backend
I think my when I tried to @InjectRepository on my service and the service into the Resolver, I started having the problem I said:

@Resolver(of => Pays)                                                            
export class PaysResolver {
  constructor(private readonly paysService: PaysService) { }   // <---- THIS IS CALLED TWICE - 1st time with `paysService` instance (instantiated by NestJS) and second time by type-graphql, with `null`.

If your's doesn't have this problem, I 'd like to examine your setup - can you please put a min working example on a repo?

@caseyduquettesc Sure, there are a lot of integration points (and pains!!!) still... We're can't wait for @nest/type-graphql@~1.0 :-)

[anodynos]

Thank you @christopherdupont - I had a look and I think it works because you're using

@Entity({ name: 't_pays' })
@ObjectType()
export class Pays extends BaseEntity

I think if you start using Repository based entities or start using more DI, you'll start facing problems.

[mohaalak]

I created a module for NestJs, combining the typegraphql and nestjs decorators, the type graphql will generate the schema from typescript and NestJS will provide the resolvers, so guards, pipes, interceptors, injection is on NestJS but schema generating is by type graphql.

https://github.com/mohaalak/nestjs_typegraphql

[kamilmysliwiec]

I have just finished POC integration locally. The biggest issue that I'm encountering frequently so far is an inconsistency between graphql libraries. Hence, I'm quite often seeing this error:
https://19majkel94.github.io/type-graphql/docs/faq.html#i-got-error-like-cannot-use-graphqlschema-object-object-from-another-module-or-realm-how-to-fix-that

which makes it almost impossible to provide a good developer experience for the end-user (calling npm dedupe is always required). This issue has been discussed here already: https://github.com/19majkel94/type-graphql/issues/192 and I see that it's not going to be fixed. However, I would love to keep type-graphql as a peer dependency (and graphql is nest peer dep as well), therefore, these libraries would be able to share the same graphql package by default. So the question goes here (cc @19majkel94): since the graphql package has to stay as a normal dependency of the type-graphql, could you expose another function which works same as buildSchema but instead of returning a schema, it would additionally call printSchema(schema) (from internal graphql-tools) and return us a string? :) For now (as a workaround), I have to emit schema to the file and afterward, read file content to get the stringified schema (what heavily affects library performance).

[MichalLytek]

@kamilmysliwiec

However, I would love to keep type-graphql as a peer dependency (and graphql is nest peer dep as well), therefore, these libraries would be able to share the same graphql package by default.

The problem is that TypeGraphQL heavily depends on graphql-js (and @types/graphql) and it's hard to control the version using peer dependencies mechanism. I can bump major version (with 0.x.y it's not a problem) when bumping peer deps minor version of graphql-js but this might fail in runtime (cannot read property 'directives' of undefined) as many people ignore npm peer deps warnings in console on install.

could you expose another function which works same as buildSchema but instead of returning a schema, it would additionally call printSchema(schema) (from internal graphql-tools) and return us a string? :)

emitSchemaFile options (as well as emitSchemaDefinitionFile helper function) are only a 3-lines wrapper around printSchema and writeFile. It doesn't change the schema building pipeline, it only acts as a helper for better DX because many people think that buildSchema return a special object, not a standard graphql-js schema.

So all you need to do is:

const schema = await buildSchema(options);
const schemaString = printSchema(schema);

I also have a PoC of building apollo-like resolversMap on a branch, this might help you with the integration:
https://github.com/19majkel94/type-graphql/tree/resolvers-map

[kamilmysliwiec]

Actually, I took a look into the source code of these functions already. The problem is that when I have tried to do the exact same thing as you proposed above^

const schema = await buildSchema(options);
const schemaString = printSchema(schema);

I was also getting the graphql inconsistency error, because in this case, buildSchema uses nested graphql dependency of type-graphql (and schema is built using this internal version) while my imported printSchema would come from another graphql package.

[MichalLytek]

@kamilmysliwiec
You're right, I will try to finish the work on generating typedefs-resolvers instead of the executable schema as soon as possible.

I will also try to find a way to detect the version of graphql in node_modules to throw error when peer dependency version isn't correct. I see that the whole ecosystem is switching to having graphql as a peer dependency, so this will solve a lot of compatibility problems.

And sorry for the late response 😞

[apiel]

@kamilmysliwiec is there any chance that you share your code to see how you attempted to integrate Type-graphql to Nest?

_I am really looking forward to be able to use Type-graphql with Nest._

[MichalLytek]

@kamilmysliwiec
Thanks to #233 and #239, you now should be able to finish your integration PoC 🎉

You can install the new 0.17.0 beta version - npm i type-graphql@next 🚀
Stable release coming soon 👀

[kamilmysliwiec]

Awesome, I'll give it a shot asap 💥

[natqe]

@kamilmysliwiec I can't wait to use Type-graphql with Nest.

[michelcve]

@kamilmysliwiec Just curious, how are things progressing with your PoC?

[kamilmysliwiec]

I'm actually ready to publish it (waiting for the stable release of type-graphql)

[michelcve]

@kamilmysliwiec That's great news! Is there a preview that works with type-graphql@next? I'm not sure how long the wait for the stable release of type-graphql is gonne be, but I fear it's still some time until 1.0.0 is ready?

[kamilmysliwiec]

@michelcve I'm saying about the 0.17.0 :)

[michelcve]

Phew ;-) (though I have no idea when that version is due ;-))

[MichalLytek]

I'm actually ready to publish it

I'm glad the changes proved to be enough to make the integration possible.

I'm finishing #180 and after that will release 0.17 stable 🚀
Then large refactoring #183 is coming 🛠

[kamilmysliwiec]

Excellent! I have just finished the docs part. #180 feature sounds awesome btw

[kamilmysliwiec]

Btw @19majkel94, so far I have to use such a workaround:

await buildSchema({
  ...options,
  emitSchemaFile,
  scalarsMap,
  resolvers: ['---.js'], // NOTE: Added to omit options validation
});

Is there a way to disable resolvers validation (additional flag?)? I don't have to instantiate any resolver during the schema creation process.

[MichalLytek]

@kamilmysliwiec
Right now resolvers are only used for triggering module evaluation (registering metadata from decorators) by require-ing files from glob paths. The schema is generated based on all registered types in global metadata storage.

In the future (#183), to allow for multiple schemas in single process with no leaks, it will strictly traverse only the modules in provided glob paths (or provided classes) to emit only the desired types, not all from the storage. So this workaround will fail and result in empty schema.

[kamilmysliwiec]

@19majkel94
Could you allow to pass an array of classes as well (instead of string glob path)? In this case, I would just traverse modules graph, extract resolvers, and pass them in the resolvers array.

[MichalLytek]

@kamilmysliwiec
Available from the beginning for over the year 😄
https://github.com/19majkel94/type-graphql/blob/fa3f69842b2ab1f5d23ab5a75edc12e814150984/src/utils/buildSchema.ts

[kamilmysliwiec]

awesome ❤️

[hexonaut]

@kamilmysliwiec Any chance you can put up the WIP code? I'd like to start integrating this into my own project.

[apiel]

https://github.com/nestjs/nest/tree/6.0.0-next

https://github.com/nestjs/nest/tree/6.0.0-next/sample/23-type-graphql

@kamilmysliwiec do you have any plan for the release of nextjs 6? Maybe for Js-kongress :D ?

[kamilmysliwiec]

hey @19majkel94,
Since #180 has been fixed 4 days ago, do you have any rough estimation when 0.17.0 will be published? 🚀

[MichalLytek]

@kamilmysliwiec I am grouping breaking changes, as some of them are coming unexpectedly, like #258.

Will try to ensure that none pending issues left and release 0.17 this week 😉

[MichalLytek]

v0.17 is out! 🚀

Spread the words, guys! 📣
https://twitter.com/typegraphql/status/1102652523326902273

[kamilmysliwiec]

Congrats @19majkel94! 🎸💥

[michelcve]

@19majkel94 Great work!

[MichalLytek]

Hey @kamilmysliwiec,

Do you have any rough estimation when Nest v6 will be published?
We're all waiting for Nest & TypeGraphQL integration 🚀

[kamilmysliwiec]

Hey @19majkel94,
Nest v6 will be published this month, ETA is next week :)

[MichalLytek]

In case someone didn't notice, Nest v6 has been released! 🎉
https://medium.com/@kammysliwiec/announcing-nestjs-6-whats-new-38959d94221f

So now TypeGraphQL is officially supported in Nest as the code first approach ❤️
https://docs.nestjs.com/graphql/quick-start#code-first

However, as discussed earlier, I will leave this issue open because I would like to provide an alternative implementation where you can use all the TypeGraphQL features, like middlewares, query complexity or other integrations (TypeORM, dataloader) that requires full control of executing resolvers methods. Maybe during the development I will introduce other concepts like custom param decorators (#45) that will allow to wrap all the Nest goodness like guards, interceptors, filters or pipes 🍾

[KristenLeach]

I'm loving the new type-graphql integration with Nest! I'm curious though, will this work with mongoose? I'm having trouble extending from Document within the new code-first syntax. I tried to extend from the class, @ObjectType() export class User extends Document{, but the service is still throwing this error: "Type 'User' does not satisfy the constraint 'Document'." I could be attempting this in the wrong place. If I write a separate User interface and extend there it works, but that defeats the purpose of reducing redundancy.

[MichalLytek]

@KristenLeach
I think that's better to use Typegoose to define Mongoose models using TypeScript classes 😉

[santutu]

Amazing intergration...

[Veetaha]

I wish we could use 'type-graphql' decorators for resolvers in NestJS. Mixing decorators from '@nestjs/graphql' with ones from this package seems odd and conter-intuitive. This also prevents users from using new functionality for resolvers from this package. Any intentions for full integration with Nest, @19majkel94, @kamilmysliwiec?

[michelcve]

@kamilmysliwiec I'm having difficulties with the integration, even your example (23-type-graphql) does not seem to work. I always get a 'Cannot return null for non-nullable field Recipe.id.'

I filed a nest.js issue here.

Not sure if it's nest.js or type-graphql related, so that's why I'm linking it here as well.

[Uldax]

@michelcve , we had the same error and it turned out that was the import: we imported resolver from type-graphql instead of @nestjs/graphql.
Be careful to import from '@nestjs/graphql' and not 'type-graphql'

[michelcve]

@Uldax Thanks a lot, that indeed did the trick!

Furthermore, the example program didn't work because the service isn't implemented. I got a similar looking error as I got in my own program, so that threw me off.

[Hossein-s]

It doesn't integrate type-graphql cool features like union types, enums, etc. I wish param decorators would bring us a way to fully integrate type-graphql and nestjs amazing features.

[kamilmysliwiec]

@Hossein-s you should be able to use both union types and enums easily.

[michelcve]

What I did notice is that the @ResolveProperty seems to be broken. No matter what I do, as soon as I add @ResolveProperty my application hangs.

It's probably related to this bug

[Hossein-s]

@Hossein-s you should be able to use both union types and enums easily.

I have checked source code of @nestjs/graphql and noticed that you are using type-graphql only for generating type definitions, not the executable schema.

So type-graphql can't generate things like enum mappings (mapping enum to internal value) and union type resolvers (resolveType method on union) this way. I'm not sure but things like inheritance and generic types may not work too.

It may be better to delegate generating executable schema to type-graphql and then wrap resolvers with Nest executors for code first approach.

[Hossein-s]

To generate a framework-context-aware resolvers, frameworks should hook in generation of executable schema.

One idea is to have a resolver factory function that takes some info needed for reflection (class reference, method, resolver type, etc...) and pass it to TypeGraphQL's buildSchema function to be applied when generating resolver.

@19majkel94 What do you think? 😃

[manzonif]

Hi,
I would like to run the following middleware in my Nestjs backend, but it is not clear to me if it is possible to implement it with the functions currently present in NestJs, (Interceptors?) Or if I have to wait for the type-graphql middlewares to be supported in NestJs.

import { MiddlewareFn } from 'type-graphql';
import { Model, Document } from 'mongoose';
import { getClassForDocument } from 'typegoose';

export const TypegooseMiddleware: MiddlewareFn = async (_, next) => {
  const result = await next();

  if (Array.isArray(result)) {
    return result.map(item => (item instanceof Model ? convertDocument(item) : item));
  }

  if (result instanceof Model) {
    return convertDocument(result);
  }

  return result;
};

function convertDocument(doc: Document) {
  const convertedDocument = doc.toObject();
  const DocumentClass: Function = getClassForDocument(doc);
  Object.setPrototypeOf(convertedDocument, DocumentClass.prototype);
  return convertedDocument;
}

[manzonif]

May be, something like this:

import { Injectable, NestInterceptor, ExecutionContext, CallHandler } from '@nestjs/common';
import { Observable } from 'rxjs';
import { map } from 'rxjs/operators';
import { Model, Document } from 'mongoose';
import { getClassForDocument } from 'typegoose';

export interface Response<T> {
  data: T;
}

@Injectable()
export class TypegooseInterceptor<T> implements NestInterceptor<T, Response<T>> {
  intercept(context: ExecutionContext, next: CallHandler): Observable<Response<T>> {
    return next.handle().pipe(map(data => {
      if (Array.isArray(data)) {
        return data.map(item => (item instanceof Model ? convertDocument(item) : item));
      }

      if (data instanceof Model) {
        return convertDocument(data);
      }

      return data;
    }));
  }
}

function convertDocument(doc: Document): any {
  const convertedDocument = doc.toObject();
  const DocumentClass: Function = getClassForDocument(doc);
  Object.setPrototypeOf(convertedDocument, DocumentClass.prototype);
  return convertedDocument;
}

[peterbabic]

Please, can someone look at https://github.com/nestjs/nest/issues/2187, if it is related - my understanding of the topic is too low. Thank You

[devniel]

I have found a simple workaround to generate an schema using the type-graphql annotations and then load it with nestjs, just overload it, in my case is fine because I'm using it to have a mock graphql schema instead of the generated with nestjs avoiding to mock the repositories and so on. I needed to apply the addMockFunctionsToSchema method to an schema generated with the raw buildSchema from type-graphql that only works well with resolvers annotated with the type-graphql annotations.

import { Resolver, Query, Mutation, Args } from '@nestjs/graphql';
import { Ctx, Query as QueryTypeGraphql, Mutation as MutationTypeGraphql, Arg } from 'type-graphql';

@Resolver(of => User)
export class UsersResolver {

  /**
   * Returns the current logger user
   */
  @QueryTypeGraphql(() => User, { 
    nullable: true,
    description: 'Returns the current logged user.'
  })
  @Query(() => User, { 
    nullable: true,
    description: 'Returns the current logged user.'
  })
  @UseGuards(UserGuard)
  async me(@Ctx() ctx) : Promise<User | undefined> {
   // ...
  }

 /**
  * Register a new user
  */
  @MutationTypeGraphql((): typeof User => User, { 
    description: 'Register a new user'
  })
  @Mutation((): typeof User => User, {
    description: 'Register a new user'
  })
  public async create(
    @Args('data')
    @Arg('data')
    {
      email,
      name,
      username,
      password,
    }: UserCreateInput): Promise<User> {
      // ...
    }
}

With that the schema can be mocked an then passed to nestjs graphql module.

// Generate a base schema from classes and decorators
    let baseSchema;
    try{
      baseSchema = await buildSchema({
        resolvers: [ __dirname + "/**/*.resolver.ts"],
      });
    }catch(e){
      console.error(e.details);
      throw e;
    }

    // Extract only types definitions
    const schemaString = printSchema(baseSchema);

    // Make a GraphQL schema with no resolvers
    const schema = makeExecutableSchema({ typeDefs: schemaString });

    // Add mocks, modifies schema in place
    addMockFunctionsToSchema({ schema });

     @Module({ 
      imports: [
        ConfigModule,
        DatabaseModule,
        UsersModule,
        AuthModule,
        GraphQLModule.forRoot({
          debug: true,
          playground: true,
          introspection: true,
          schema: schema,
     //...

[unlight]

I'm trying to integrate NestJs + type-graphql + Prisma 2
Facts:

1. I want to use code first approach
2. I want to use generated typegraphql revolvers (by node_modules/typegraphql-prisma/generator.js)
   Example of generated FindOneUserResolver

import { Arg, Args, ArgsType, Ctx, Field, FieldResolver, Float, ID, InputType, Int, Mutation, ObjectType, Query, Resolver, Root, registerEnumType } from "type-graphql";
import { FindOneUserArgs } from "./args/FindOneUserArgs";
import { User } from "../../../models/User";

@Resolver(_of => User)
export class FindOneUserResolver {
  @Query(_returns => User, {
    nullable: true,
    description: undefined
  })
  async findOneUser(@Ctx() ctx: any, @Args() args: FindOneUserArgs): Promise<User | null> {
    return ctx.prisma.user.findOne(args);
  }
}

The problem that is Nest do not see decorator Resolver from type-graphql. It expects from @nestjs/graphql.
I've tried to put this FindOneUserResolver to nest module providers, GraphQLModule options under buildSchema -> resolvers.

In playground I see that resolvers from type-graphql affected on schema, but they are returning null.

Is it not yet supported? Or I'm doing something wrong...

Update:
After playing some time I found that I must use Args, Context, Mutation, Query, ResolveProperty, Resolver decorators from '@nestjs/graphql', but still using other generated classes partially, e.g. FindManyUserArgs, etc. Playground repository - https://github.com/unlight/nest-typescript-starter

[MichalLytek]

@unlight
You may use this fork: https://github.com/EndyKaufman/typegraphql-prisma-nestjs

As stated earlier, in the future you gonna be able to use just typegraphql-prisma when the Nest integration will support plain TypeGraphQL decorators 😉

[unlight]

In fact this fork is not using nestjs. All is spinning around type-graphql, prisma and direct usage of ApolloServer. :D

[EndyKaufman]

this repo use nestjs https://github.com/EndyKaufman/typegraphql-prisma-nestjs-example, nestjs need for use guards and pipes from nest world

[unlight]

Nest v7 broke my nest+graphql+prisma2 app.
https://docs.nestjs.com/migration-guide#graphql

In order to migrate your existing application, simply rename all the type-graphql imports to the @nestjs/graphql

Looks like importing decorators from type-graphql is not compatible anymore.
How we can fix generated models, args, etc.?
Is it possible to add option to generator typegraphql to specify import moduleSpecifier?

[MichalLytek]

@unlight
I'm afraid that due to embedding the fork of TypeGraphQL inside NestJS 7, the official TypeGraphQL - Prisma 2 integration won't gonna work with the new Nest's GraphQL layer anymore.

Please check out @EndyKaufman Nest-based fork or create an issue on Nest GraphQL repository with a feature request.

Basically, we've returned to the starting point, where we need to revamp the simple integrations like https://github.com/MichalLytek/type-graphql/issues/135#issuecomment-423345833 or nestjs-type-graphql for those people that want to use TypeGraphQL, not a Nest's variant.

As stated a year ago, somewhere in the future there will be available fully-fledged integration that will allow to use Nest's guards, interceptors, etc. in the TypeGraphQL resolvers 😉

[wSedlacek]

@unlight I do have a PR in @EndyKaufman Nest-based fork to support NestJS 7.
To fix the imports is quite simple however the problem is deciding what to do for NestJS <= 6.

[clayrisser]

Support nest 7 and then have a fork that supports nest 6. Just an idea.

[EndyKaufman]

Original Typegraphql inputs and objects can use in frontend, when sharing it with mono repository between backend and frontend, but in nestjs 7 is break it, now I try add support this feature for nestjs 7

[EndyKaufman]

If use only in backend fork work may work correct, but I use inputs and object not only backend, I use it in frontend on angular

[wSedlacek]

@EndyKaufman To avoid issues like that my work flow is as follows:

Backend:

1. Setup Prisma Schema
2. Generate NestJS Resolvers using TypeGraphQL Generator
3. Import into NestJS modules.

Frontend:

1. Write GraphQL Queries/Mutations
2. Generate Apollo Angular request services using GraphQL Code Generator
3. Import into Angular services.

This means I only ever need to write the Prisma Schema and the GraphQL request and I get type safety on the frontend and backend and my GraphQL request can be as simple or complicated as I want them to be.

It also means that the server and client are decoupled in a sense that neither project are importing from the same library but still type safe through code generation.

[clayrisser]

@wSedlacek I've been doing the same thing, except I'm using react :)

[MichalLytek]

I've spend yesterday's afternoon on working on the basic integration of TypeGraphQL with NestJS, and here it is - typegraphql-nestjs 🎉

This integration provides a way to use TypeGraphQL with NestJS modules and dependency injector. For now it doesn't support other NestJS features, so you have to use standard TypeGraphQL equivalents.

The "how to use it" instruction and some code examples are available on the repo:
https://github.com/MichalLytek/typegraphql-nestjs

Plese check it out and let me know how it works for you guys (or which features are missing, apart from the guards or pipes) 😉

[RafaelKr]

That's awesome news! Now I wonder if this makes @nestjs/graphql obsolete?

@kamilmysliwiec Will this be the new official way to combine NestJS with TypeGraphQL in the future?

[MichalLytek]

Will this be the new official way to combine NestJS with TypeGraphQL in the future?

They have copied and embedded the modified TypeGraphQL source code into @nestjs/graphql so I doubt that they will be interested in making integration with TypeGraphQL as you can just use their code-first solution 😉

[RafaelKr]

I'm just about to start a new project. And I did understand that @nestjs/graphql already uses type-graphql under the hood.
That's why I'm asking if it's recommended to use @nestjs/graphql or your new typegraphql-nestjs.

I also read this part in https://www.npmjs.com/package/typegraphql-nestjs#caveats:

Moreover, with typegraphql-nestjs you can also take advantage of additional features (comparing to @nestjs/graphql) like inline field resolvers, query complexity or Prisma 2 integration.

But I do not quite understand what the difference is.

[MichalLytek]

And I did understand that @nestjs/graphql already uses type-graphql under the hood.

https://trilon.io/blog/announcing-nestjs-7-whats-new#GraphQL-TypeScript

[devniel]

Hi, @RafaelKr , @nestjs/graphql doesn't use type-graphql, you can check its package.json, I think that it has mimicked the code to be "injectable" so it could work with the NestJS DI system. For instance, if you use @nestjs/graphql, you write your resolvers the same way as type-graphql and then you want to use those resolvers with some type-graphql methods such as buildSchema, it won't work because the types are different. That issue is solved with this plugin (I don't know about the DI issues), thanks @MichalLytek 🎉 !!

[XBeg9]

@MichalLytek is there a possible workaround to get pipes, guards working using https://www.npmjs.com/package/typegraphql-nestjs?

[MichalLytek]

@XBeg9 They use their own ExternalContextCreator to generate GraphQL resolver functions, so it's not possible for now to use Nest's pipes or guards using TypeGraphQL execution stack.

[Mi3liX9]

Will guards and pipes be supported in the future?

[theMitch36]

has anyone (@MichalLytek) gotten Nestjs to work with graphql code-first in lambda?

[wSedlacek]

has anyone (@MichalLytek) gotten Nestjs to work with graphql code-first in lambda?

Are you referring to AWS Lambda Functions?
You should check out this repo
https://github.com/lnmunhoz/nestjs-graphql-serverless

The main difference from a regular NestJS application is the way the entrypoint works.
In this repo they use serverless.ts as the entry point.