Explain how does the request is sent and recieved and how does the data flows in a Graphql api.

Question

Accepted Answer

GraphQL operates over a single endpoint (usually `/graphql`) and uses HTTP POST by convention. Unlike REST where each resource has its own endpoint, the client sends a structured query that specifies exactly what data it needs. The server processes this query through a pipeline of parsing, validation, and execution, then returns a JSON response that matches the shape of the query. All of this happens in a single round trip, eliminating over-fetching and under-fetching. # HTTP Request
POST /graphql HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer token123

{
  "query": "query GetUser($userId: ID!) { user(id: $userId) { id name email posts { title } } }",
  "variables": { "userId": "123" },
  "operationName": "GetUser"
}

# The query string is sent as a JSON field. Variables are separate to avoid string concatenation.
# The client specifies exactly which fields it needs (id, name, email, posts with title).
# The server will not return any extra fields beyond what is requested. **Query String**: The client constructs a GraphQL document defining the operation. This includes field selections and can include fragments for reuse. **Variables**: Dynamic values are passed separately in a variables object, preventing injection attacks and allowing query reuse. **Operation Name**: Optional but recommended when multiple operations exist in one document. **HTTP Method**: POST is standard, though GET can be used for queries (with query string in URL) with proper caching headers. **Headers**: Authentication tokens, content-type, and other headers are sent as with any HTTP request. **Parse**: The server receives the raw string and parses it into an Abstract Syntax Tree (AST). If syntax errors exist, the server returns a 400 error with details. **Validate**: The AST is validated against the schema. This checks that fields exist, types match, and required arguments are provided. Validation happens before execution, ensuring malformed queries are rejected early. **Execute**: The server traverses the AST depth-first, invoking resolvers for each selected field. The execution is driven by the query's selection set, not the schema. **Collect**: Resolver results are collected and assembled into a data object that mirrors the query structure. **Return**: The final JSON response is serialized and sent back to the client, with errors (if any) in a separate errors array. # 1. Parse: Query string to AST
query = parse(request.query);

# 2. Validate against schema
validate(schema, query);

# 3. Execute depth-first
result = {};
for field in query.selectionSet:
    resolver = getResolver(field.type, field.name);
    value = resolver(parent, field.args, context);
    if field has subfields:
        # Recursively resolve nested fields
        result[field.name] = resolveSubfields(value, field.selectionSet);
    else:
        result[field.name] = value;

# 4. Return response
response = { data: result, errors: executionErrors } The resolver execution creates a directed graph based on the query. Starting from the root Query or Mutation, **resolvers are invoked depth-first.** Each resolver can fetch data from different sources (databases, REST APIs, caches) and can be asynchronous. Parent resolvers pass their result to child resolvers via the `parent` argument. This allows for hierarchical data fetching: a `User` resolver might return a user object, and the `posts` field resolver for that user uses the user's `id` to fetch associated posts. // Query: { user(id: 123) { name posts { title } } }

// Resolver execution order (depth-first, left to right):
// 1. Query.user(parent, { id: 123 }) → returns user object
// 2. User.name(parent) → returns name from user object
// 3. User.posts(parent) → returns array of posts
// 4. Post.title(parent) → returns title from each post

const resolvers = {
  Query: {
    user: (_, { id }) => fetchUserFromDB(id)      // Database call 1
  },
  User: {
    posts: (user) => fetchPostsByAuthor(user.id)  // Database call 2 (for user)
  }
};

// Total database calls: 1 user query + 1 post query = 2 calls
// REST would need: /users/123 and /users/123/posts (2 calls as well)
// But GraphQL eliminates over-fetching: only requested fields are returned **data**: Contains the result of the query if execution succeeded. Mirrors the shape of the query exactly. Null fields may appear if data was not found. **errors**: Array of error objects, each with a message, path (to the field that caused error), and optional extensions. Errors do not block partial data—successful fields are still returned. **extensions**: Optional metadata for tooling, performance timing, or custom debugging info. {
  "data": {
    "user": {
      "id": "123",
      "name": "Alice",
      "posts": [
        { "title": "GraphQL Basics" },
        { "title": "Advanced GraphQL" }
      ]
    }
  },
  "errors": [
    {
      "message": "Failed to load comments",
      "path": ["user", "posts", 0, "comments"],
      "extensions

Explain how does the request is sent and recieved and how does the data flows in a Graphql api.

Scenario Questions

Follow-up Questions