Challenge 2: Write a deletePost Mutation — Possible Solution ==================================================================== // Schema type Mutation { createPost(input: CreatePostInput!): Post! updatePost(input: UpdatePostInput!): Post! deletePost(id: ID!): Boolean! } // Resolver Mutation: { // ...existing createPost, updatePost resolvers... deletePost: (parent, args, context) => { return db.posts.delete(args.id); // returns true/false depending on success }, } WHY THIS PARTICULAR MUTATION REASONABLY RETURNS A BOOLEAN -------------------------------------------------------------- After a successful delete, the object no longer exists — there is nothing left to query fields FROM, so returning the deleted Post itself (as createPost and updatePost do) isn't meaningfully possible the way it is for a create or update, where the object still exists afterward for the client to immediately query further details from in the same round trip. WHY THIS WORKS -------------- - id: ID! is taken directly as a plain scalar argument here, rather than wrapped in an input type — this is a legitimate and common exception: input types exist to group multiple related arguments together cleanly, but a mutation needing only a single simple scalar argument (like "which ID to delete") doesn't gain anything from being wrapped in a dedicated input type just for the sake of consistency. - Returning Boolean! (rather than a nullable Boolean) is deliberate: the mutation should always be able to report definitively whether the delete succeeded or not — there's no legitimate "unknown" outcome state for a delete operation the way there might be for some other more ambiguous operations. - This is exactly the "few reasonable cases" the challenge alludes to: the general convention from the chapter (return the affected object) exists specifically so a client can immediately query further data about what it just created or changed — a convention that simply doesn't apply once the underlying object has been removed entirely.