Skip to content
This repository has been archived by the owner on Sep 2, 2022. It is now read-only.

Resolver Payload Types #743

Closed
sorenbs opened this issue Oct 7, 2017 · 12 comments
Closed

Resolver Payload Types #743

sorenbs opened this issue Oct 7, 2017 · 12 comments

Comments

@sorenbs
Copy link
Member

sorenbs commented Oct 7, 2017

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

Scalar

#729 proposal/accepted
#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 ...

#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
Copy link
Contributor

marktani commented Oct 7, 2017

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?

@kbrandwijk
Copy link
Contributor

A huge 👍 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!

@kbrandwijk
Copy link
Contributor

@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
Copy link
Contributor

marktani commented Oct 7, 2017

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

@kbrandwijk
Copy link
Contributor

@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
Copy link
Contributor

marktani commented Oct 7, 2017

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.

@kbrandwijk
Copy link
Contributor

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...?

@gaurav107
Copy link

Any updates on this?

@jvbianchi
Copy link

Will this be part of 1.0 (#353)?

@marktani
Copy link
Contributor

This issue has been moved to graphcool/graphcool-framework.

@anaibol
Copy link

anaibol commented Apr 22, 2018

@marktani: I think that you could link directly to the issue on graphcool-framework repo on this cases :)
I am trying to find if there is any news about this.

@marktani
Copy link
Contributor

Here's the issue: Graphcool/graphcool-framework#256.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants