What is the main problem with this resolver organization?
medium
A. The schema is missing a Subscription resolver
B. The Post.author resolver ignores the parent post and fetches unrelated author data
C. Resolvers must be async functions, but these are not
D. The Query.posts resolver should be inside Mutation
Solution
Step 1: Analyze Post.author resolver
The author resolver does not use the parent post argument, so it cannot fetch the correct author for each post.
Step 2: Understand resolver context
Field resolvers should use the parent argument to access related data; ignoring it causes wrong or unrelated data.
Final Answer:
The Post.author resolver ignores the parent post and fetches unrelated author data -> Option B
Quick Check:
Use parent argument in nested resolvers [OK]
Hint: Nested resolvers must use parent to access related data [OK]
Common Mistakes:
Ignoring parent argument in nested resolvers
Misplacing Query resolvers inside Mutation
Assuming all resolvers must be async
5. You want to organize resolvers for a GraphQL server with Queries, Mutations, and a custom type Book. Which structure below best supports maintainability and scalability?
hard
A. const resolvers = { Query: {...}, Mutation: {...} }; // no Book resolvers