Resolver Payload Types - Githubissues

marktani commented 6 years ago

Issue by sorenbs Saturday Oct 07, 2017 at 15:16 GMT Originally opened as https://github.com/graphcool/prisma/issues/743

Resolvers return a payload that can be constructed in many different ways:

Scalar

https://github.com/graphcool/graphcool/issues/729 proposal/accepted https://github.com/graphcool/graphcool/issues/742

Return one of the supported scalar types:

extend type Query {
  add(a: Int! b: Int!): Int!
}

module.exports = function sum(event) {
  return {data: 7}
}

Note: are enums Scalar?

Transient

note: we might need a better term than Transient ...

https://github.com/graphcool/graphcool/issues/543 proposal/needs-spec

Return a type that is not stored in the Graphcool database:

type Post {
  title: String
  content: String
}

extend type Query {
  getTopPost(category: String): Post!
}

module.exports = function(event) {
  return {data: {title: "Some Title", content: "Some Content"}}
}

Model

Return a type that is stored in the Graphcool database:

type Post @model {
  title: String
  content: String
}

extend type Query {
  getTopPost(category: String): Post!
}

module.exports = function(event) {
  return {data: "cuidfnewi2342423432123456"}
}

cuidfnewi2342423432123456 must be the id of an existing Post node. Graphcool takes care of linking everything up correctly.

Nested Transient

Transient types can be arbitrarily nested:

type category {
  name: String!
  posts: [Post!]!
}

type Post {
  title: String
  content: String
}

extend type Query {
  getTopPosts(category: String): Category!
}

module.exports = function(event) {
  return {data: {name: event.data.name, posts: [{title: "Some Title", content: "Some Content"}]}}
}

Note: Proposal should take into account how validation should work. Nested resolver types opens up the possibility for 1) a very deep object structure, which might not be included in the query 2) recursive payload structure

Combined Transient and Model

Model types can be returned from Transient type:

type category {
  name: String!
  posts: [Post!]!
}

type Post @model {
  title: String
  content: String
}

extend type Query {
  getTopPosts(category: String): Category!
}

module.exports = function(event) {
  return {data: {name: event.data.name, posts: ["cuidfnewi2342423432123456"]}}
}

marktani commented 6 years ago

Comment by marktani Saturday Oct 07, 2017 at 15:34 GMT

Model

Permissions for querying nodes

I think querying nodes should behave the same as all other queries in terms of the permission system.

Query arguments for model fields

Is it possible to include/exclude query arguments for [Post!]! and Post/Post! fields?

marktani commented 6 years ago

Comment by kbrandwijk Saturday Oct 07, 2017 at 17:29 GMT

A huge :+1: on the proposal for how to return an model Type. I've been thinking about this, because returning the actual object is not feasible because of relations that are not part of the returned data. The solution with the id is a wonderful solution to it!

marktani commented 6 years ago

Comment by kbrandwijk Saturday Oct 07, 2017 at 17:33 GMT

@marktani Interesting addition on the permissions. However, that would require the user token, not the PAT, to execute queries inside resolver functions. So you would need both tokens as part of the context.

marktani commented 6 years ago

Comment by marktani Saturday Oct 07, 2017 at 17:38 GMT

no, checking permissions would be handled by the framework that has access to the node token.

marktani commented 6 years ago

Comment by kbrandwijk Saturday Oct 07, 2017 at 17:48 GMT

@marktani Can you explain how that would work. I'm especially concerned in what I can do as a developer to influence that behavior. I have the 'freedom' to execute queries using the root token (or whatever it's called now). Then, if I return an Id from such a query, the users' permissions would suddenly be applied automatically? I definitely think that's not something I want.

marktani commented 6 years ago

Comment by marktani Saturday Oct 07, 2017 at 18:02 GMT

That's how I imagine it to work, but I see that this is not necessarily the desired behavior in all cases.

On the other hand, exposing all data connected to nodes returned in a resolver is probably also not desired.

marktani commented 6 years ago

Comment by kbrandwijk Saturday Oct 07, 2017 at 18:05 GMT

So maybe 'just' returning the Id of a Node is not enough for the 'internals' to know how to deal with this. Maybe we need a different syntax, an object like { nodeId: "....", token: "..." } to indicate which id we want to return, and how to retrieve it. Or { nodeId: "....", applyPermissions: true | false }. Or...?

marktani commented 6 years ago

Comment by gaurav107 Sunday Oct 29, 2017 at 06:30 GMT