Advanced GraphQL test (Advanced)

Sample questions

5 sample questions from the Advanced GraphQL test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.

1. What is the impact of removing an enum value from a GraphQL schema?

   1. Removing an enum value from a GraphQL schema is a breaking change because clients using that value will no longer receive valid responses.
   2. Removing an enum value is not a breaking change because the server can automatically map old values to new ones.
   3. Removing an enum value is not a breaking change because GraphQL supports backward compatibility by default.
   4. Removing an enum value is not a breaking change because clients can fall back to default values.

   Answer: A. Removing an enum value from a GraphQL schema is a breaking change because clients using that value will no longer receive valid responses.

   In GraphQL, removing an enum value is considered a breaking change because it affects existing clients that may still be using that value. Clients relying on the removed value will encounter errors or unexpected behavior since the value is no longer recognized by the server. This is why it is important to track usage with telemetry before removing any enum values and to deprecate them first with `@deprecated` before removal.

2. What happens when the DataLoader is used in the provided JavaScript code to fetch user data for 50 posts, each with an `authorId`?

   1. The DataLoader batches the user IDs and fetches all users in a single database call, reducing the number of database queries from 50 to 1.
   2. The DataLoader makes 50 separate database calls to fetch each user individually, increasing the number of queries.
   3. The DataLoader returns an error because it cannot handle multiple user IDs at once.
   4. The DataLoader ignores the user IDs and fetches all users from the database, regardless of the provided IDs.

   Answer: A. The DataLoader batches the user IDs and fetches all users in a single database call, reducing the number of database queries from 50 to 1.

   The DataLoader is designed to batch multiple requests into a single call, which significantly reduces the number of database queries. In this example, instead of making 50 separate queries to fetch 50 user IDs, the DataLoader collects all the IDs and makes one batched query, improving performance and reducing database load.

3. In a project where a list of posts is fetched and each post has an 'author' field that requires a database lookup, which of the following is the most effective way to optimize performance and avoid the N+1 problem?

   1. Use DataLoader to batch and cache the user lookups within the same request.
   2. Replace the author field in the Post type with a computed field that avoids database lookups.
   3. Fetch each author individually for every post in the list.
   4. Cache the author data globally across all requests to avoid repeated lookups.

   Answer: A. Use DataLoader to batch and cache the user lookups within the same request.

   In a project where a list of posts is fetched and each post requires the associated author's details, using DataLoader ensures that all author IDs are collected and batched into a single database query. This prevents the N+1 problem and improves performance by reducing the number of database calls. Other options either fail to address the batching issue or introduce unnecessary complexity.

4. In an Apollo Federation setup, a query is made for a Product type that is defined in both the products and reviews subgraphs. What will the router do next?

   1. The router will not call any subgraphs and will return an error because the Product type is defined in multiple subgraphs.
   2. The router will only fetch the Product type from the products subgraph and not call _entities on the reviews subgraph.
   3. The router will call __resolveReference on the products subgraph to resolve the reviews field.
   4. The router will call _entities(representations: ...) on the reviews subgraph, which will run __resolveReference to resolve the reviews field.

   Answer: D. The router will call _entities(representations: ...) on the reviews subgraph, which will run __resolveReference to resolve the reviews field.

   In Apollo Federation, when a query is made that involves an entity type (like Product) that is defined across multiple subgraphs, the router will first fetch the entity from one subgraph and then call _entities(representations: ...) on the other subgraphs to resolve the fields that are defined there. The __resolveReference function is used in the subgraphs to resolve the entity based on the representations provided by the router.

5. Which of the following is a common mistake or tricky edge case when deprecating an interface type in GraphQL schema evolution?

   1. Deprecating an interface type without using the @deprecated directive is not allowed in GraphQL.
   2. Deprecating an interface type is safe as long as the type is not used in any resolvers.
   3. Deprecating an interface type always breaks all queries and must be avoided.
   4. Deprecating an interface type without first ensuring that no active clients depend on it can lead to unexpected client errors or broken queries.

   Answer: D. Deprecating an interface type without first ensuring that no active clients depend on it can lead to unexpected client errors or broken queries.

   When deprecating an interface type, it is crucial to ensure that no active clients are relying on it. If clients are still using the interface, removing or deprecating it without proper migration or telemetry can result in errors or broken queries. This is a common mistake during schema evolution, as clients may not immediately adapt to changes in interface types.