GraphQL Skills Assessment

GraphQL's defining advantage in this scenario is the elimination of the N+1 round-trip problem at the API layer: the client describes exactly the shape of data it needs in one query, and the server returns precisely that in one response. Twelve sequential REST calls with serial dependencies can be replaced by one GraphQL query, dramatically reducing page load time especially on high-latency mobile connections. GraphQL uses JSON over HTTP (not binary encoding), does not provide automatic CDN caching (HTTP caching is actually harder with GraphQL), and requires authentication like any other API.

This is the classic N+1 problem in GraphQL. One query fetches the 100 posts (the '1'), then the author resolver fires once per post for each of the 100 authors, totalling 101 database queries. In production this causes severe performance degradation. The solution is DataLoader, which batches all author ID lookups collected during a single execution tick into a single SELECT WHERE id IN (...) query, reducing 101 queries to 2. N+1 is the most common and impactful performance issue in GraphQL API implementations.

DataLoader works by collecting all the keys requested during one GraphQL execution tick (one event loop cycle) and then issuing a single batched query for all of them. By creating DataLoader instances per request for both reviews (batch by product IDs) and users (batch by user IDs), the entire nested query resolves in 3 database calls regardless of how many products, reviews, or users are returned. DataLoader also provides per-request memoization so the same user record is never fetched twice in the same request.

GraphQL's flexibility means a malicious or poorly written client can construct exponentially expensive queries - a single deeply nested query can trigger thousands of database calls. Query depth limiting rejects queries that exceed a maximum nesting depth (typically 5-10 levels). Query complexity analysis assigns a cost to each field and rejects queries whose total cost exceeds a threshold. These two mechanisms together prevent denial-of-service via query complexity. Disabling introspection in production is a best practice but does not prevent known attackers from crafting expensive queries manually.

Over-fetching (mobile receiving the full user object when it only needs 3 fields) and under-fetching (web needing to make multiple calls to assemble the full profile) are the two core inefficiencies GraphQL was designed to solve. Because clients specify the exact shape of their query, both the mobile app and web dashboard query the same single /graphql endpoint but receive precisely the data they requested. This eliminates the need for mobile-specific REST endpoints and reduces payload sizes on bandwidth-constrained clients.

False. In GraphQL, queries are used to read (fetch) data without side effects, while mutations are used to write or modify data on the server. This mirrors the REST distinction between GET (safe, read-only) and POST/PUT/DELETE (data-modifying). The naming is intentional: 'mutation' explicitly signals that the operation changes state. Subscriptions are a third operation type used for real-time data via WebSockets. Confusing query and mutation semantics is a common error in early GraphQL implementations.

False. GraphQL schemas support object types, interface types, union types, enum types, and scalar types as field return values. Object types are the core building blocks of any schema - for example, a User type can have a posts field that returns a list of Post objects, which in turn have an author field returning another User. Scalar types (String, Int, Boolean, ID, Float, and custom scalars like DateTime) are the leaves of the type tree. This rich type system is what enables GraphQL's introspection and client tooling.

HTTP caching is a genuine structural advantage of REST for read-heavy public APIs: GET requests are cacheable by URL, enabling CDN and browser caching without additional infrastructure. GraphQL typically uses POST requests, which are not cached by HTTP caches by default, requiring Apollo Server-side caching or persisted queries as workarounds. The ecosystem familiarity argument is real for public APIs where you cannot control the developer's toolchain. GraphQL's introspection in production is a security consideration but not a fundamental argument against GraphQL. REST is not inherently faster at the protocol level.

Resolvers are the functions that fulfill each field in a GraphQL query. They fetch data from the appropriate source (database, microservice, cache), apply business logic including authorization checks on sensitive fields, and return values that match the schema's expected type. Schema validation (option B) is the responsibility of GraphQL's execution engine, which validates incoming queries against the type system before any resolver is invoked. Mixing schema validation into resolver logic is an anti-pattern that adds unnecessary complexity.

DataLoader, originally developed by Facebook, works by collecting all the keys passed to its load() function during a single event loop tick, then calling a user-defined batch function once with all the collected keys. This converts N individual database calls into a single batch query. DataLoader also provides per-request memoization, preventing duplicate fetches of the same record within one request. It should be instantiated per request (not shared across requests) to prevent data leaking between users.

In GraphQL, a union type enables a field to return multiple possible object types, enhancing flexibility in data modeling. This is particularly beneficial for scenarios where a single query might yield different types of results, such as a search function that can return various entities like Users, Posts, or Products. By using a union, developers can define a single field that can dynamically resolve to any one of the specified types, allowing for more complex and versatile queries while maintaining type safety.

GraphQL subscriptions are designed for real-time communication, allowing clients to receive updates automatically when specific events occur on the server. In the context of a real-time auction platform, pushing live bid updates to all connected clients ensures that participants are instantly informed of new bids, enhancing engagement and competitiveness. This scenario exemplifies the primary advantage of subscriptions, which is to maintain an active connection for continuous data flow, making it ideal for situations requiring immediate updates rather than static data retrieval.

GraphQL schemas utilize introspection to enable clients to query the schema's type system, including its available fields and documentation, at runtime. This powerful feature allows developers to dynamically explore and understand the API without needing external documentation. By leveraging introspection, clients can discover types, relationships, and operations, facilitating easier integration and more efficient development processes. This capability enhances the flexibility and usability of GraphQL, making it a robust choice for building APIs.