GraphQL execution is field-oriented, but the exact execution behavior depends on the operation and server implementation.

A useful conceptual model is that sibling fields can often be resolved independently, while fields that depend on parent objects are resolved after their parent values are available.

For example:

query {
  user(id: "42") {
    id
    name
    posts {
      id
      title
    }
  }
}

The user field must produce the parent object before posts can use that user value. Once an object is available, its selected child fields can be evaluated according to GraphQL's execution semantics.

This matters when writing asynchronous resolvers.

For example:

const resolvers = {
  Query: {
    dashboard: async (_, __, context) => {
      const [profile, notifications] = await Promise.all([
        context.profileService.getProfile(),
        context.notificationService.getNotifications()
      ]);

      return { profile, notifications };
    }
  }
};

Application-level concurrency can reduce latency when independent data sources can safely be queried in parallel.

However, parallel execution is not a reason to fire unlimited database queries. Connection pools, downstream service limits, rate limits, CPU, memory, and query complexity must all be considered.

Later chapters will cover DataLoader, batching, caching, query complexity, and performance controls.