GraphQL Course for Beginners

Summary of Technological Concepts & Features (GraphQL Beginner Course)

What GraphQL is and why it’s used

• GraphQL is described as a query language (the “QL” in the name) with its own syntax for requesting queries and changing mutations data.
• Compared to REST:
  • REST typically uses multiple endpoints (e.g., GET /resource, POST /resource) and often returns entire objects.
  • GraphQL commonly uses a single HTTP endpoint (e.g., /graphql), and data fetching is driven by the GraphQL query syntax on top of HTTP.
• Key advantages emphasized:
  1. Avoiding over-fetching: REST might return fields you don’t need; GraphQL lets clients request only specific fields.
  2. Avoiding under-fetching: REST may require multiple calls to assemble nested/related data; GraphQL can fetch nested related data in one request.

Course plan / tutorial scope (beginner-friendly)

• Built as a fresh, up-to-date version (notes that an older course was ~5 years old with “less bloat”).
• Teaches:
  • GraphQL fundamentals and its benefits over REST
  • Building a GraphQL server from scratch using Node.js and Apollo Server
  • Testing queries using Apollo Explorer (browser-based tool, similar to Postman for REST)
  • Writing and understanding:
    • Queries
    • Query variables
    • Nested/related data traversal
    • Mutations (create/add, delete, update)

Tooling and setup details

• Node.js prerequisites: assumes basic Node.js knowledge and a recent Node version from nodejs.org.
• Course code repo on GitHub with branches per lesson (download specific lesson code via branch, or clone the entire repo).
• Uses:
  • Apollo Explorer automatically for testing the API on localhost
  • Mentions Apollo Sandbox as an alternative dummy server for experimentation

---

GraphQL query syntax and core mechanics

Query structure

• Queries start with the keyword query and use curly braces {} to specify:
  • Which schema entry point/resource you want (e.g., reviews, games, authors)
  • Exactly which fields you want returned per object (field selection)

Querying lists vs single objects

• Initially, schema entry points expose list endpoints (e.g., reviews: [Review]).
• Later, the schema expands to support single-item entry points (e.g., review(id: ID!): Review) using query variables.

Query variables

• Variables are declared in the query, following a pattern like:
  • query ($id: ID!) { review(id: $id) { ... } }
• Variables are passed via Apollo Explorer’s “variables” panel as JSON key-value pairs.
• Used to fetch a specific object by ID (single review/game/author).

Graph traversal / nested related data

• The graph conceptually models connected types (e.g., reviews ↔ authors, reviews ↔ games).
• GraphQL supports nesting so related data can be retrieved in one request instead of multiple REST calls.
• Demonstrated nested queries:
  • Fetch a game → fetch its reviews → fetch review fields
  • Fetch a review → fetch its author and game
  • Fetch an author → fetch their reviews

---

Apollo Server architecture (schema + resolvers)

Apollo server setup

• Uses @apollo/server and startStandaloneServer.
• Server setup uses:
  • typeDefs (schema/type definitions)
  • resolvers (resolver functions for fetching data)

Schema (typeDefs) content

• Uses built-in scalar types: Int, Float, String, Boolean, plus special ID.
• Defines custom object types (example course types):
  • Game (fields like id, title, platform: [String])
  • Review (fields like id, rating: Int, content)
  • Author (fields like id, name, verified: Boolean)
• Defines root entry points in:
  • type Query { ... } (initially lists: reviews, games, authors)
  • Later adds single-object entry points using arguments:
    • review(id: ID!): Review
    • game(id: ID!): Game
    • author(id: ID!): Author
• Adds relationships to types for nested data:
  • Review includes game: Game! and author: Author!
  • Game includes reviews: [Review]
  • Author includes reviews: [Review]

Resolver functions

• Root resolvers under resolvers.Query implement list and single fetches:
  • reviews() → returns DB.reviews
  • games() → returns DB.games
  • authors() → returns DB.authors
  • review(_, args) → finds by args.id
  • Similarly for game and author
• A local “database” file (_db.js) is used (arrays of objects) rather than a real database.

Resolving nested data via resolver chaining

• When requesting nested fields (e.g., game { reviews { ... } }), Apollo needs resolvers to connect relationships.
• Implemented nested resolvers such as:
  • resolvers.Game.reviews(parent) → filters reviews by review.game_id === parent.id
  • resolvers.Author.reviews(parent) → filters reviews by review.author_id === parent.id
  • resolvers.Review.game(parent) → finds the game by review.game_id
  • resolvers.Review.author(parent) → finds the author by review.author_id
• Emphasis on resolver chains: parent objects from earlier resolvers are passed via the parent argument to later resolvers.

---

Mutations (create, delete, update)

Mutation fundamentals

• Mutations are introduced as schema changes that can:
  • add new data
  • update existing data
  • delete data
• GraphQL requires:
  • type Mutation in the schema
  • corresponding resolvers.Mutation functions

Delete mutation: removing a game

• Schema example concept:
  • deleteGame(id: ID!): [Game] (returns updated list of games)
• Resolver logic:
  • Updates local DB.games by filtering out the game matching args.id
  • Returns the updated array

Add mutation: creating a new game

• Uses an input type to group mutation arguments:
  • input AddGameInput { title: String!, platform: [String]! }
• Mutation returns a Game object (the newly created one).
• Resolver logic:
  • Generates a random ID (using Math.floor(Math.random() * 10000))
  • Pushes the new game into DB.games

Update mutation: editing an existing game

• Uses a separate input type allowing partial updates:
  • input EditGameInput { title: String, platform: [String] } (fields not required)
• Mutation signature includes:
  • updateGame(id: ID!, edits: EditGameInput!): Game
• Resolver logic:
  • Uses DB.games.map(...) to replace the matching game by ID, merging existing properties with args.edits
  • Returns the updated game (via DB.games.find(...))

Persistence note

• Since mutations use local in-memory arrays, changes persist only for the current server session; restarting resets data.

---

Key speaker / source

• Main speaker: “Net Ninja” (instructor; referred to as one of the most popular GraphQL instructors on the internet).
• Primary referenced documentation/tool sources: Apollo Server docs, Apollo Explorer, Apollo Sandbox, nodejs.org.