Challenge 3: Explain a Schema Validation Error — Possible Solution
====================================================================

THE INVALID SCHEMA
---------------------
type Mutation {
  createPost(post: Post!): Post!  // fails to build
}

WHY GRAPHQL REJECTS THIS
---------------------------
A regular type (like Post) is meant to represent something the SERVER
produces — every field on it is backed by a resolver function (even if
that resolver is just the default one reading a matching property), and
its fields can themselves reference OTHER resolver-backed types (e.g.
Post.author returning a full User, which itself has its own resolved
fields). None of that makes sense for something arriving as an ARGUMENT
from the client:

- When a client sends a mutation argument, it's sending plain,
  structured DATA — there's no "resolver" involved on the way in, and
  there's no server-side computation happening for whatever the client
  is handing over. A type's entire reason for having resolver-backed
  fields is irrelevant for something that's just going to be read as
  static input values (args.post.title, etc.).
- If Post could be used as an argument, and Post.author resolves to a
  full User object (which might itself contain fields resolving to yet
  other types), it becomes genuinely unclear what a CLIENT sending a
  "Post" as input is even supposed to provide for a field like author —
  a full nested User object? Just an ID? The type was never designed
  with "being sent in as input" in mind, so its shape doesn't cleanly
  answer that question.
- GraphQL's type system solves this by requiring a completely separate
  input keyword for anything used as a structured argument — an input
  type's fields are guaranteed to be plain, resolver-free data (no
  ambiguity about how they'd be "resolved," since nothing needs
  resolving on the way in), which is exactly the guarantee needed for
  something being read as literal client-supplied values.

THE FIX
--------
input CreatePostInput {
  title: String!
  authorId: ID!
}

type Mutation {
  createPost(input: CreatePostInput!): Post!
}

Defining a separate, purpose-built input type — even though it looks
similar to parts of Post — gives the schema an unambiguous, resolver-free
shape for what the client is actually expected to send, while
createPost's RETURN type can still legitimately be the full,
resolver-backed Post type, since that's data flowing back OUT from the
server, not data structure being sent IN by the client.