Passing down a context from a node to its descendents for checking permissions.

[joonhocho]

Say that I have a user object.

Here's how it looks.

user: {
  info: {
    email: {
      address: String!
    }
  }
  friends: [ID]!
}

When User A tries to access User B's info.email.address, A's ID must be present in the B's friends field.
When resolving address field of email object, it currently has no way to access the friends field of its owner user B (unless I am missing something).

I wish there is a way to add some context value to pass down to its subtree nodes and their fields so they can use it when resolving.
For example, user object type wants to add itself as a context value for its descendent node fields, and the fields resolvers can access it as context.user.
This is very similar to how context works in React via childContextTypes and getChildContext.

[joonhocho]

For referece of how React's context works. https://facebook.github.io/react/docs/context.html

[dschafer]

#301 has a discussion of this and why we didn't add the ability. In particular, having different contexts in the same query causes major issues for client caches, which can now see conflicting values for the same object and field.

However, https://github.com/graphql/graphql-js/blob/master/src/graphql.js#L43 allows the caller to pass down a context for the entire query. This context is most commonly used to contain authentication information.

So the resolver for address could know that the email is for user B, and get authentication info for user A, and use that to determine whether it is visible.

Hope this helps!

[joonhocho]

What if the query looks like this?

users {
  info {
    email {
       address
    }
  }
}

In this case address resolver does not know which user it belongs to, because the query is querying for multiple users.

[joonhocho]

@dschafer, in case you don't get notified.

[dschafer]

If the ability to see the address depends on whose address it is, I would expect the object returned by email to have a reference to the User; at that point, you would do:

address: {
resolve: (email, _, context) => context.isFriendsWith(email.getUser()) ? email.getAddress() : null
}

Though better than that would be to have that logic live inside the email business object:

class Email {
getAddress(context) {
return context.isFriendsWith(getUser()) ? this.address : null;
}
getUser() {
return this.user; // The email knows about the user because the address visibility depends on it
}
}

address: {
resolve: (email, _, context) => email.getAddress(context)
}

This way, every caller of Email.getAddress() has the desired visibility rules applied.

[joonhocho]

Thank you for your answer!
So far, I've been using plain javascript objects for resolving data trying to go as vanilla as possible.
Now I see the need for wrapping data objects with model classes.