在 GraphQL 操作中使用嵌套的 arguments

Question

I have a schema like so:

scalar Date

schema {
  query: Query
}

type Query {
  user(id: ID!): User
  messages(userId: ID!): [ChatMessage!]!
}

type User {
  id: ID!
  username: String!
  email: String!
}

type ChatMessage {
  id: ID!
  content: String!
  time: Date!
  user: User!
}

And I want to make an operation where you can get all messages for a user, but since User and ChatMessage are in separate database tables I would need to perform two queries (one to get the ChatMessages and one to get the User ), so I thought I should model it like so:

query findMessagesForUser($userId: ID!) {
  messages(userId: $userId) {
    id
    content
    user(id: $userId) {
      username
      email
    }
  }
}

This returns a parse error on the schema:

GraphQLDocumentError: Unknown argument "id" on field "ChatMessage.user".

So, how do I get the $userId argument passed to the resolver for ChatMessage.user ?

Answer 1

In your schema, you've defined an id input on your Query.user method. In your query, you are trying to supply an id to the Message.user property, however you haven't defined this input in your schema.

If you wanted to accept an id on ChatMessage.user, you'd need to define it as:

type ChatMessage {
  id: ID!
  content: String!
  time: Date!
  user(id: ID!): User
}

However, it wouldn't really make sense (at least to me) to construct a schema this way, I assume there's only one user (author) per message.

As indicated by @xadm, the object you resolved at the ChatMessage level will be passed into the user resolver as the first argument.

Even if you're not exposing ChatMessage.userId in the schema (that's fine), you'd still probably load this up in your back- end (the foreign key value in the ChatMessage table) and set this on the object used to resolve ChatMessage.

This way, you'll (lazy) load user IF that's included in the query, using the userId property of the parent ChatMessage object argument (remember you don't need to expose ChatMessage.userId via the schema, it's just on the object you use to resolve ChatMessage).

I'd consider modelling more like this (filter input used as an additional contrived example):

type Query {
  user(id: ID!): User
  messages(filter: MessageFilter): [ChatMessage!]!
}

type MessageFilter {
  search: String
  paging: PagingFilter 
}

type PagingFilter {
  after: ID!
  pageSize: Int!
}

type User {
  id: ID!
  username: String!
  email: String!
  messages(filter: MessageFilter): [ChatMessage!]!
}

In your resolver map, you can wire up the same function to resolve messages at the User level and at the Query level. The only difference is you wouldn't have a userId at the Query level.

If consumers want to view/search messages from all users, they use the top level Query messages method.

{
  messages({search: 'graphql'}) {
   id,
   content,
   time
  }
}

If the consumer wants to view/search one user's messages, go through the top level Query users method into messages.

{
  user(id: 3) {
    messages({search: 'graphql'}) {
     id,
     content,
     time
    }
  }
}

The filter example is contrived, but could provide basic paging for loading of messages.

apollographql.com/docs/graphql-tools/resolvers