Resolvers return a payload that can be constructed in many different ways:
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?
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"}}
}
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 existingPost
node. Graphcool takes care of linking everything up correctly.
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
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"]}}
}
Model
I think querying nodes should behave the same as all other queries in terms of the permission system.
Is it possible to include/exclude query arguments for [Post!]!
and Post
/Post!
fields?
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 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.
no, checking permissions would be handled by the framework that has access to the node token.
@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.
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.
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...?
Any updates on this?
Will this be part of 1.0 (#353)?
This issue has been moved to graphcool/graphcool-framework.
@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.
Here's the issue: https://github.com/graphcool/graphcool-framework/issues/256.
Most helpful comment
Any updates on this?