Challenge 1: Write a Schema for a Comment System — Possible Solution
====================================================================

type Comment {
  id: ID!
  text: String!
  author: User!
}

type Post {
  id: ID!
  title: String!
  author: User!
  comments: [Comment!]!
}

WHY THIS WORKS
--------------
- Comment follows the exact same pattern as User and Post from the
  chapter's own example schema: an ID! field (every comment needs a
  stable, non-null identifier), a String! field for its actual content
  (a comment without text doesn't make sense, so non-null is the right
  choice here, just like Post's title), and an author field pointing to
  the EXISTING User type rather than duplicating user fields inline —
  reusing types this way is exactly how a growing schema stays
  consistent as more object types reference each other.
- comments: [Comment!]! on Post uses the strictest, most common list
  form from this chapter's nullability table — a post's list of
  comments is guaranteed to exist (even if it's an empty array for a
  post with no comments yet) and every individual comment in that list
  is guaranteed to be a real, non-null Comment object, never a null
  placeholder sitting in the array.
- This mirrors the exact relationship already established between User
  and Post in the chapter (a User has posts: [Post!]!) — Post now having
  comments: [Comment!]! extends the same one-to-many pattern one level
  deeper, which is a completely ordinary way for a schema to grow as
  more related data needs modeling.
- author: User! (non-null) is a deliberate choice: it reflects that
  every comment genuinely DOES have exactly one author in this domain —
  a comment without an author wouldn't be a valid comment at all, so
  making this field nullable would incorrectly suggest that an
  authorless comment is a normal, expected possibility.