GraphQL support

[leonard-henriquez]

Do you plan to have GraphQL support?

[samchon]

As I've not used it yet, have no insight about it.

Can you tell me which points of gql in NestJS are inconvenient, so that how feature do you want in nestia?

[briandiephuis]

I'm still getting to grips with Nestia, but is looks awesome. Here are my inconveniences with input validations in GQL in NestJS:

NestJS has a great GraphQL plugin to minimize the overhead in declaring DTOs; https://docs.nestjs.com/graphql/cli-plugin. This cleans up the number of decorators to create a GraphQL schema (in a code-first approach).

GraphQL is already typed, as in, it knows when you set the input as an Int, it will error out if you provide a String. However, you still need validators to set -for example- Min and Max values for that Int. Unfortunately, in the world of class-validator, we now need to tell it it is supposed to be an integer again, where we already did so for the GraphQL plugin. Removing these duplicate settings would be awesome.

import { Field, InputType, Int } from '@nestjs/graphql';
import { IsInt, IsOptional, Max, Min } from 'class-validator';

@InputType()
export class CreateEntityInput {
  /** Number items */
  @Field(() => Int)
  @IsInt() // Should ideally not be needed as we already told @Field that it is an Int
  @Min(0)
  @Max(100)
  @IsOptional() // Should ideally not be needed as it is already marked as  ?:`
  readonly numberOfItems?: number; // The ?: is picked up by the GraphQL CLI plugin and makes the field optional
}

[samchon]

Understood. Reading @nestjs/gql, I understood how it terrible and torturing users.

At first, I will make typia.gql<T>(): string function, that generates GQL schema through TS type. And after that, I'll make @nestia/gql which can develop GQL features much easier.

Until those step, I recommend you to use [typia.assert<T>()] function for a while. You can validate gql data through it, without declaring class-validator schema.

• https://typia.io/docs/validators/assert

[L-U-C-K-Y]

Thanks @samchon GraphQL would be awesome for us too!

[elijaholmos]

I am using the GraphQL schema-first approach. Would migrating my application to Nestia be worth it, or is a majority of the performance boost available to traditional REST API applications?

[L-U-C-K-Y]

I am using the GraphQL schema-first approach. Would migrating my application to Nestia be worth it, or is a majority of the performance boost available to traditional REST API applications?

@elijaholmos where are you using GraphQL and where REST? Client-Server and/or Server-Server?

[elijaholmos]

@L-U-C-K-Y I have a GraphQL API running server-side. My frontend client communicates with this GraphQL API over HTTPS. REST is not used anywhere in my application.

[samchon]

As I have many features to develop, this feature may start from 2023-08.

ASAP, I'll write my open source development roadmap describing my projects and their processes.

Until that, if you have any good idea about new interface, please tell me.

[ziyadev]

Understood. Reading @nestjs/gql, I understood how it terrible and torturing users.

At first, I will make typia.gql<T>(): string function, that generates GQL schema through TS type. And after that, I'll make @nestia/gql which can develop GQL features much easier.

Until those step, I recommend you to use [typia.assert<T>()] function for a while. You can validate gql data through it, without declaring class-validator schema.

• https://typia.io/docs/validators/assert

Thank you that will be great

[samchon]

This is my schedule, and will try to finish this feature in October or November.

https://github.com/samchon/schedules