Intermediate GraphQL test (Intermediate)
30 questions · 35 minutes · Free
DataLoader and N+1, pagination, auth, errors and subscriptions.
Take the Intermediate GraphQL test
What it covers
- GraphQL N+1 and DataLoader
- GraphQL pagination with connections
- GraphQL authentication and authorization
- GraphQL error handling
- GraphQL subscriptions
Interview format
- Questions: 30 questions — 18 multiple choice, 9 multi-answer, 3 predict-the-output
- Time: 35 minutes, timed from the first question
- Difficulty: Intermediate
- Skill area: Backend
- Price: Free
Earn a certificate
The Intermediate GraphQL test is one of the 8 tests of the Backend Developer learning path. Pass it and the other 7 tests at 70% or more and readyforhires issues you a verifiable certificate in your name, with its own code and verify link to share or add to LinkedIn.
Sample questions
5 sample questions from the Intermediate GraphQL test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.
Which statement correctly describes how DataLoader handles requests and caching?
- DataLoader batches requests and resolves them in the same order as the keys, using a cache per request to avoid N+1 issues.
- DataLoader uses a global cache for all requests and resolves them in any order, which may cause N+1 issues.
- DataLoader resolves each request individually and does not use any caching, which is inefficient for large datasets.
- DataLoader resolves requests in reverse order of the keys and does not support caching, making it unsuitable for production use.
Answer: A. DataLoader batches requests and resolves them in the same order as the keys, using a cache per request to avoid N+1 issues.
DataLoader is designed to batch requests and resolve them in the same order as the keys provided. It also uses a cache per request to avoid the N+1 problem, ensuring that each request is handled efficiently. Other options are incorrect because they either misrepresent the batching behavior or the caching scope.
In a GraphQL API, how should session management be implemented to ensure that a user is authorized to access sensitive data across all fields in a query?
- Use a session token stored in the context and validate it on each resolver to ensure the user is authorized to access the requested data.
- Check authentication only at the top-level query and assume all nested fields are accessible to the user.
- Trust client-provided IDs without verifying ownership or authorization for the requested data.
- Do not use session tokens and rely solely on GraphQL subscriptions for session management.
Answer: A. Use a session token stored in the context and validate it on each resolver to ensure the user is authorized to access the requested data.
In GraphQL, session management involves using a session token (such as a JWT) stored in the context, which is validated on each resolver to ensure that the user is authorized to access the requested data. This ensures that each field in the query is checked for authorization, preventing unauthorized access to sensitive data. Other options are incorrect because they either suggest relying on the top-level query for authorization (which is insufficient), using client-provided IDs without ownership checks (which can lead to data leaks), or not using session tokens at all (which would leave the system vulnerable to unauthorized access).
You have a mutation that updates a user's data. After the mutation, you need to invalidate the DataLoader cache for the affected user. Which of the following is the correct approach?
- The DataLoader cache should be cleared for the specific user ID after the mutation.
- The DataLoader cache should not be cleared after the mutation.
- The DataLoader cache should be cleared for the global loader after the mutation.
- The DataLoader cache should be cleared for all users after the mutation.
Answer: A. The DataLoader cache should be cleared for the specific user ID after the mutation.
When a mutation updates a user's data, the DataLoader cache for that specific user ID should be cleared to ensure subsequent queries retrieve the latest data. The cache should not be cleared for all users or global loaders, as this would unnecessarily invalidate data for other users. DataLoader instances are created per request, so clearing the cache for the specific user ID after the mutation is the correct approach.
What is the primary purpose of implementing query depth limits in a GraphQL API?
- It limits the maximum depth of nested queries to prevent overly complex or resource-intensive operations.
- It limits the total number of fields that can be requested in a single query.
- It limits the size of the response payload returned by the server.
- It limits the number of queries that can be executed in a single request.
Answer: A. It limits the maximum depth of nested queries to prevent overly complex or resource-intensive operations.
GraphQL query depth limits are used to restrict the maximum depth of nested queries in a GraphQL API. This helps protect the server from potential abuse, such as deep nesting that could lead to performance issues or excessive resource consumption. By enforcing a depth limit, the server ensures that queries remain manageable and secure.
Which of the following is a best practice for using DataLoader instances in a production GraphQL API?
- DataLoader instances should be created globally to maximize performance and reduce memory usage.
- DataLoader instances should be created per user session to ensure that the cache is specific to each user.
- DataLoader instances should be created per request, not globally, to ensure that the cache is specific to each request and does not leak data between users.
- DataLoader instances should be created once and reused for all requests to ensure consistency across the application.
Answer: C. DataLoader instances should be created per request, not globally, to ensure that the cache is specific to each request and does not leak data between users.
DataLoader instances should be created per request rather than globally because the cache is a memoization cache for a single request. Using a global DataLoader instance across requests can lead to data leakage between users, which is a significant security risk. This is a best practice for using DataLoader in production applications.
Frequently asked questions
- How many questions are in the Intermediate GraphQL test?
- 30 questions (18 multiple choice, 9 multi-answer, 3 predict-the-output), with 35 minutes to answer them.
- What does the Intermediate GraphQL test cover?
- GraphQL N+1 and DataLoader, GraphQL pagination with connections, GraphQL authentication and authorization, GraphQL error handling, GraphQL subscriptions.
- Is the Intermediate GraphQL test free?
- Yes. It is free to take with a readyforhires account.
- What level is the Intermediate GraphQL test?
- Intermediate, in Backend.