NestJS support

[vabatta]

Hi, I've been exploring for GQL and found out about this package, and I wonder if you ever considered to weave also into NestJS so that one can use this gqloom with like zod and wire it up into NestJS.

[xcfox]

If you only use NestJS as an adapter, using GQLoom in NestJS is very simple.

You just need to pass the Schema weaved by GQLoom to GraphQLModule, like this:

import { Module } from '@nestjs/common';
import { GraphQLModule } from '@nestjs/graphql';
import { ApolloDriver, ApolloDriverConfig } from '@nestjs/apollo';
import { AppController } from './app.controller';
import { schema } from './graphql';

@Module({
  imports: [
    GraphQLModule.forRoot<ApolloDriverConfig>({
      driver: ApolloDriver,
      schema,
      graphiql: true,
    }),
  ],
  controllers: [AppController],
  providers: [],
})
export class AppModule {}

I've created a simple example: https://stackblitz.com/edit/nestjs-typescript-starter-xugidczl?file=src%2Fgraphql%2Findex.ts

[vabatta]

Yeah no, I was actually looking into building a proper integration through decorators so you it can leverage DI and all the other nestjs ecosystem packages.

[vabatta]

I'll see how far I can get, shouldn't be too hard!

[xcfox]

I recommend checking out: https://github.com/incetarik/nestjs-graphql-zod, this library uses zod to build GraphQL types in nestjs

[xcfox]

Before developing GQLoom, I had carefully considered: Could I create a plugin for NestJS | TypeGraphQL, allowing us to use existing resolver builders and leverage the established NestJS | TypeGraphQL ecosystem?

After weighing development experience and type safety, I abandoned the idea of building a plugin because the Decorator that NestJS | TypeGraphQL relies on cannot provide comprehensive type inference and type checking.

For example, building a GraphQL API using NestJS Code-First mode has too much code redundancy and type unsafety:

import { Field, ID, ObjectType, Args, Parent, Query, ResolveField, Resolver } from '@nestjs/graphql';

@ObjectType('Giraffe')
export class Giraffe {
  @Field(() => ID) // ID for GraphQL type
  id: string; // string for TypeScript type

  @Field(() => String, { description: 'The giraffe\'s name' }) // String for GraphQL type
  name: string;  // String for TypeScript type

  @Field(() => Date)  // Date for GraphQL type
  birthday: Date;  // Date for TypeScript type
}

@Resolver(() => Giraffe) // Giraffe for GraphQL type
export class GiraffeResolver {
  @Query(() => GiraffeModel)
  giraffe() {
    return {
      id: 'g1',
      name: 'Melman',
      birthday: new Date('2000-05-12'),
    };
  }

  @ResolveField(() => Number)
  age(
    @Parent() giraffe: Giraffe, // Giraffe for TypeScript type
    @Args('currentDate', {
      type: () => Date, // Date for GraphQL type
      nullable: true,
      defaultValue: () => new Date(),
    })
    currentDate: Date, // Date for TypeScript type
  ): number {
    return currentDate.getFullYear() - giraffe.birthday.getFullYear();
  }
}

Furthermore, if you write completely incorrect types, TypeScript cannot detect the issue, such as:

@ObjectType('Giraffe')
export class Giraffe {
  @Field(() => String) // String for GraphQL type
  id: number; // number for TypeScript type, it's wrong but TypeScript can't tell

  @Field(() => String, { description: 'The giraffe\'s name' }) // String for GraphQL type
  name: number;  // number for TypeScript type, it's wrong but TypeScript can't tell

  @Field(() => Date)  // Date for GraphQL type
  birthday: number;  // number for TypeScript type, it's wrong but TypeScript can't tell
}

ORMs that rely on decorators like TypeORM have the same issue.

This critical problem also prompted tRPC to give up class-based syntax.

In the long run, ECMAScript decorators will replace Legacy Decorators, but ECMAScript decorators are missing some key features in comparison.

Personally, I'm not optimistic about the application of Decorator features. If type-related problems remain unresolved, decorators will gradually decline in usage.

[vabatta]

I would have envisioned something like

@GQLoomResolver(FileSchema)
export class UploadResolver {
  private readonly logger = new Logger(UploadResolver.name);

  public constructor() {}

  @GQLoomMutation(z.string())
  public async uploadFile() {}

  @GQLoomQuery(FileSchema)
  public async getFile(
    @ZodArgs('fileKey', z.string()) fileKey: string,
    @ZodArgs('meta', z.json().optional()) meta?: JsonValue,
  ) {}

  @GQLoomField(...)
  ...
}

Which doesn't look too bad - yes you need to type parameters and return types, but given the predominance of such a shaggy framework (still used by many in prod because now too big to refactor) I think could give this project still some well worth visibility.

I got a tiny toy prototype working for the aforementioned example, absolutely not feature complete, but I got a sense that it would be possible.

To further expand on what you said - I agree about the type-safety loss, but for NestJS users this is a known trade-off.