Prisma1: Support resolver types in types.graphql

[sorenbs]

Currently the schema for a resolver must be defined in a separate file:

graphcool.yml

functions:
  facebook-authentication:
    handler:
      code:
        src: ./src/facebook-authentication.js
    type: resolver
    schema: ./src/facebook-authentication.graphql

facebook-authentication.graphql

type AuthenticateFacebookUserPayload {
  token: String!
}

extend type Mutation {
  authenticateFacebookUser(facebookToken: String!): AuthenticateFacebookUserPayload
}

In the future we will keep supporting this setup. Additionally we will support placing all types in the types.graphql file:

types.graphql

type FacebookUser @model {
  id: ID! @isUnique
  facebookUserId: String @isUnique
  facebookEmail: String
  createdAt: DateTime!
  updatedAt: DateTime!
}

type AuthenticateFacebookUserPayload {
  token: String!
}

extend type Mutation {
  authenticateFacebookUser(facebookToken: String!): AuthenticateFacebookUserPayload @resolver(handler: "facebook-authentication")
}

Also note that we now use the @model directive to distinguish between model types that are backed by the database and "free types" that can be used in resolvers

Rationale

Placing all types in one file makes it easier to reuse payloads between resolvers.

It is still possible to organise your Graphcool application into modules with individual types.graphql files

[sorenbs]

@sorenbs Define how this will work for current stable CLI

[marktani]

I have one big consideration here: when this is implemented, you are able to create types however you wish. It would be obvious to think that you now can do something like this:

type Person implements Node {
  id: ID! @isUnique
  name: String!
  field: Address
}

type Address {
  street: String!
  number: Int!
}

Which is not part of this feature request.

While I think this is out of scope for now, this is definitely an important feature that has been proposed before:

• https://github.com/graphcool/graphcool/issues/162
• https://github.com/graphcool/graphcool/issues/77

We need to think about how to best communicate these limitations, as it's quite easy to run into problems here.

[marktani]

Just updated the proposal to the @resolver(handler: "facebook-authentication") syntax.

[sorenbs]

@marktani I actually do think this should be @resolver(function: "facebook-authentication") as it is referencing a function name in graphcool.yml :-)

[marktani]

Got it! I confused this with an earlier, now obsolete, proposal.

[kbrandwijk]

@marktani I wouldn't put a bit more Type flexibility for resolvers out of scope for this FR, because I think it's a natural match with including all types in types.graphql.

[kbrandwijk]

With the possibilities to define project configuration that the local workflow or the CLI offers, I don't believe that this should be part of the schema. There are other ways to define storage configuration for types (for example in the project file). I feel that attributes defined in the schema should not be used for this.

[flux627]

It is still possible to organise your Graphcool application into modules with individual types.graphql files

I can't seem to find how you can do this in any documentation. Can anybody point me in the right direction?

[marktani]

Modules was a concept temporary available during the Framework preview. Due to several limitations, it has been replaced by a much simpler concept of templates: https://github.com/graphcool/framework/issues/720.

You can find a list of the officially supported templates here: https://github.com/graphcool/templates. At the moment, there is no built-in support for improved code organization, but there is some movement in the community around this topic. More information here: https://www.graph.cool/forum/t/code-organization/1352?u=nilan

[marktani]

Discussion is continued in #743.