Schema directives support

[MichalLytek]

Partially solved by #369

Currently blocked by graphql/graphql-js#1343

---

Ability to define any arbitrary graphql directive to be passed to the compiled schema:

@ObjectType({ directives: ['@cacheControl(maxAge: 240)'] })
class SampleObject {
  // ...
}

Which should be equivalent to:

type SampleObject @cacheControl(maxAge: 240) {
  # ...
}

It might be also implemented as a separate decorator that would make possible to create custom decorators like @CacheControl({ maxAge: 240 }):

@Directive('@cacheControl(maxAge: 240)')
@ObjectType()
class SampleObject {
  // ...
}

[JasCodes]

@19majkel94 Why this is blocked? at face seems less complicated.

[MichalLytek]

Go to the link in first post and read the discussion 😉
If you can implement this - feel free to make a PR 😃

[ntziolis]

This sadly prevents anybody from being able to use type-graphql that is using graphcool/prisma as a backend. We would love to use it but sadly without being able to generate the schema necessary by the downstream tooling its a non starter :(

[MichalLytek]

@ntziolis
AFAIK, Prisma is the glue between your GraphQL server and your database.
You define your model using SDL and you receive a generated client that acts as an ORM in your server app.

So there should be no problem to use Prisma along with your GraphQL API build with TypeGraphQL. Of course, the tighter integration (defining prisma model and your API GraphQL Object Type in one class with decorators) would help in reducing boilerplate, but I think it's not a deal breaker 😉

[MichalLytek]

And to report an update about the status of the issue - now I think I understand where is the problem with directives in graphql-js. They are purely the SDL thing, so tools written in different languages can parse the schema definition and apply certain behaviors in runtime.

So as with graphql-js we define a runtime JS object, other tools (like Prisma or Apollo Engine) don't have an access to the directives. That's why we have to wait for a new GraphQL specification that will expose the directives info via an introspection query. For now the only workaround is to generate typeDefs and resolversMap instead of executable GraphQLSchema and paste the "directives" from metadata storage into proper lines in SDL string 😕

[ntziolis]

@19majkel94 I understand the first instinct, but there are various reasons why we feel when solving this issue a lot of other goodness would come from it:

• prisma has a VERY poor data model migration story, in particular:
  • no versioning of schema during dev time
  • deployment of the same schema causes deployment errors in many cases breaking CI pipelines
  • no support for up/down migrations
• using partial or changed types in public schema only possible via copy&paste
  • using the same types in your public schema minus a few fields requires copy&pasting the type (and related types) and manually removing the fields in question
  • causes errors when our devs update prisma data model but forget todo the same on the public side (lets be honest this happens a lot)

In order to clean this up and follow DRY here is how we wanted to use type-graphql

• type-graphql becomes our way of defining both public & prisma schema (including generating the actual SDL files)
• at the same time be able to generate type safe resolvers for the public schema
• and use the additional features to standardize on DI etc most of which is handled manually / project by project today with different libs

I understand this might have been the initial intention of type-graphql but I can tell you after the 10th+ graphql project: The need for a framework that is the beginning and end where types originate is VERY high especially when using a graphql datasource underneath (we have tried various beyond prisma).

[Hossein-s]

Hi @19majkel94

I was trying to undestand the problem for long hours 😄 As far as I found apollo graphql-tools is doing simple job for schema directives. It just finds fields with directives and overrides their resolvers with enhanced version that applies that specific directive.

So as TypeGraphQL stores metadata for first part, the second part can be done the same way.

I don't know what you want to provide for prisma. The datamodel of the prisma is not a graphql thing. it's a customized version so I think it has nothing to do with TypeGraphQL that cares about server - client relation.