Apollo provides a universal GraphQL API on top of your existing services, so you can build new application features fast without waiting on backend changes.

apollo

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

graphql

Most developers would raise an eyebrow if they saw database queries being done in a for-loop, but GraphQL provides just enough abstraction that it isn't always intuitive exactly how many times each resolver fires at scale, nor is it obvious how to batch operations efficiently and still return the correct results to the correct consumer.

You'll learn how to use the GraphQL Data Loader pattern to improve the performance of your application, and solve scaling issues before they become a problem.

To do this, we'll first implement our own naive version of the pattern to understand why the API is shaped how it is. Then we will switch over to the official DataLoader package and explore the benefits further.

## Skills you'll Gain

- Implement a cache layer to optimize your requests
- Batch requests so your Database isn't overloaded
- Build a performant GraphQL API

It's easy enough to use GraphQL to query an array of posts from a database. But if you try to include the author of each post, you can run into scaling issues where the server makes an additional request for each and every post.

Using the console, we'll show how to identify when this is happening

And by the end of this series, you'll know how to use data loaders to prevent it.


Detect Scaling Issues When Loading Data In a GraphQL API

We're going to build a cache that sits between the GraphQL resolvers and the database and ensures we only have to fetch each user once, while later requests for the same users will return them from the cache immediately


Cache Database Requests Across GraphQL Resolvers

Querying a thousand posts doesn't have to mean a thousand individual database requests.

We're going to build a batching layer that adds a millisecond pause into each resolver while it gathers all the required post IDs and then fetches them in a single request


Batch Database Requests with a GraphQL API

We can make this data loader reusable by refactoring it into a class with configurable scheduling and batch functions

Refactor the Data Loader into a Reusable Class

If a cache persists between requests, a logged-in user could cache some sensitive data that guest users could access by mistake

An easy way to prevent this is to make new DataLoaders on every request using Apollo's context method, which also makes it easy to inject the DataLoader into any resolver


Create a New Cache on Every GraphQL Request Using Apollo Context

The GraphQL Foundation has an official DataLoader package that is well-maintained and more feature complete than what we've built so far.

Install the DataLoader Package

The DataLoader class is reusable and creating a new loader is as simple as changing the batch function

Fetching an Item by ID with a GraphQL DataLoader

One-to-many relationships are a prime candidate for scaling issues. In this lesson we'll add a new loader to fetch all the comments for a given post ID.

Fetching Many Items by Key with GraphQL DataLoaders

The simplest way to count the comments on a post is to use a Data Loader that returns all of the comments and return the length.

As long as the primary access pattern is to always fetch the number of comments along with the comments themselves, the Data Loader will batch them together and you'll get the count for free with no extra database requests.

Count the Items in a Collection By Reusing a Data Loader

If users will be often querying the number of comments without also querying the list of comments

Then fetching the entire comment collection is wasteful. It's also not compatible with any pagination features that don't return the entire collection.

In this lesson, we will create a custom Data Loader specifically for counting items

Count the Items in a Collection with a Custom Data Loader

After the course, you’ll be ready to communicate with a GraphQL API regardless of server-side implementation using the GraphQL query language.

GraphQL Query Language

Through exploration and comparison, you'll come away with actionable knowledge for designing and extending schemas.

Designing GraphQL Schemas

First, a guide on how to add the Apollo client to an existing project, then move on using the Query and Mutation components to fetch and manipulate data using a GraphQL API.

GraphQL Data in React with Apollo Client

Use GraphQL Data Loaders to Prevent Scaling Issues by Batching & Caching Database Requests

https://app.egghead.io/api/v1/lessons/apollo-detect-scaling-issues-when-loading-data-in-a-graphql-api/subtitles

Instructor: [0:00] This is an Apollo GraphQL application with a Postgres database that contains a table of posts and a table of users. We have a post query that returns an array of posts, and a users query that returns an array of users.

[0:14] Let's query the posts. We can see every item in the database is returned, and the users query does the same for the users. What we're looking to accomplish here is to extend the post query to also return the user who wrote the post.

[0:29] We can start by adding a new field to the schema named author, with a return type of user. Then if we scroll down to the resolver section for the post type, and add an author field, we'll return a list of users where the ID matches the post's author ID.

[0:47] Since we only want one, grab the first one from the array. Let's try that request out with the author, ID, and the name. Let's see. We get all the author information for each post, so it's working here.

[1:02] It's a little hard to tell what the database is actually doing here. We'll add some console logs to track how many times we're interacting with the database. Under posts, we'll do console log, select all from posts.

[1:15] Under author, we'll do console log, select all from users, where ID = post.author ID. If we run our request again, we can see we're only making one database request to fetch the list of posts.

[1:36] We're also making individual requests for the author on each post including several requests for the same author. At the end of this series, we'll show how to use DataLoaders for caching and batching database operations so that we can serve all of these results with only one database request.

https://app.egghead.io/api/v1/lessons/apollo-detect-scaling-issues-when-loading-data-in-a-graphql-api/transcript

https://app.egghead.io/api/v1/lessons/apollo-cache-database-requests-across-graphql-resolvers/subtitles

Instructor: [0:00] To implement a cache, we need to add a layer of abstraction between the resolver and the database request. That cache layer is responsible for deciding whether request actually queries the database or just returns a cached value.

[0:13] Let's create an object named cache with a method named load, and copy paste the database request from the author resolver. Then the author resolver can just call cache.load with the author ID and everything should work just like it did before.

[0:32] We can send the same request multiple times and it still hits the database every time. We'll give the cache a promises object that will work like a map or a dictionary. The keys in the object are the user IDs we've tried to load. The values are the database request for that user ID.

[0:48] We can guard this function with a check to see if the promises object already contains this key. If so, return the promise from the cache. If it doesn't, then we add the database request to the cache and return it.

[1:02] To make it easier to see what's going on, we'll add a console.log, cache hit for key. If we query the post now, we can see that every user that was called more than once, responds first from the database, and then from the cache. That's users 1, 2, and 4.

[1:17] No database entry is called twice. That's good. If we send a second request, every user is served from the cache again and will continue to be until the server restarts. That's bad, but we'll fix that shortly.

https://app.egghead.io/api/v1/lessons/apollo-cache-database-requests-across-graphql-resolvers/transcript

https://app.egghead.io/api/v1/lessons/apollo-batch-database-requests-with-a-graphql-api/subtitles

Instructor: [0:00] Batching is the second layer of abstraction, where instead of resolving requests immediately, we pause for a bit. Then we take every ID that was requested over that pause and do one single query to fetch all of them. Let's call that Active Query, and we'll make it null by default.

[0:16] To pause, we need to make a new Promise with a short timeout. One millisecond is OK here. Longer will allow bigger batches but will also make the request slower. Our batch size will be every ID in the Promise's cache, which gives us everything we've requested so far.

[0:32] Bring the database query code here, and we'll tweak it to accept a list of IDs instead of just a single one. That's going to be SELECT ALL FROM users WHERE ID IN (IDs). .where() becomes .whereIn(), and pass it all of the IDs from the Promise cache. We don't just want the first item anymore, so we can return .first(), and this becomes ActiveQuery instead.

[0:56] If we're fetching the list of IDs from the cache, then we're always going to be missing the current one if it's not a cache yet. There's lots of ways to fix that, but we can just add it to the cache and be done with it.

[1:08] The Promise for each item key is going to start with the common act of query, which returns every item in this batch, and then branch off with .then() to find and return the specific ID for this item.

[1:23] We resolve the Promise for this key, which is being returned from the load method for this key. Last thing, once this patch has started, we don't need to dispatch it again. Only do that if we haven't set ActiveQuery yet. Let's test this out.

[1:40] We have one request for posts and one request for all of the users at once. Before, a thousand posts would do a thousand individual author requests. Now it will be one request no matter how many posts we have.

[1:51] Running this a second time shows our cast still works across multiple network requests. Since there's no guarantee those requests come from the same person, that means a logged in user could cast some sensitive data the guest users could access by mistake. We're going to have to fix that.

https://app.egghead.io/api/v1/lessons/apollo-batch-database-requests-with-a-graphql-api/transcript

https://app.egghead.io/api/v1/lessons/apollo-refactor-the-data-loader-into-a-reusable-class/subtitles

Instructor: [0:00] Hard coding the timeout to one millisecond batch sizes limits the flexibility of this API. We'll make a new method called scheduling function and copy the timeout logic from the load method there. We can replace the resolve with a return.

[0:21] We just have to await the scheduling function to put the timeout back into effect. The next tree factor is to extract the database operation into configurable batch function method. We can use this loader for more than just selecting users by ID.

[0:37] Let's stop here and make sure everything still works. One way to make the batch function configurable is to turn this into a class, so we can have a userLoader instance and a postLoader instance.

[0:50] The only difference is they pass different batch function parameters when we construct them with the DataLoader. Rename the cache to class DataLoader, and in the constructor, assign promises and active query as member variables. Set the batch function here too, from an argument to the constructor. Then the scheduling function is optional so we can hide that behind an options object.

[1:16] Throw an error not implemented, if there's no batch function. We can create userLoader as a new DataLoader. Pass in a batch function that takes keys, select all from users, where ID in keys. Replace the old cache.load call with user loader call and try it out.

[1:47] It's looking like everything still works and our refactor was successful.

https://app.egghead.io/api/v1/lessons/apollo-refactor-the-data-loader-into-a-reusable-class/transcript

https://app.egghead.io/api/v1/lessons/apollo-create-a-new-cache-on-every-graphql-request-using-apollo-context/subtitles

Instructor: [0:00] Right now, we're creating userLoader when the server starts, and we don't have any code to purge the cache between requests, so a second query for the same item is still served from the cache. Network caches like this are a good idea, but this isn't the place for them. Server RAM is expensive, and this implementation can cause major security risks.

[0:20] We can eliminate all of that by using a cache that only exists for the duration of a single network request. We're going to do that by making new DataLoaders on every request using Apollo's context method. Copy the userLoader directly from its declaration into the Apollo context. It'll be available as the third argument to every single resolver.

[0:44] Now, we can see the caching and batching working flawlessly on a per-request level.

https://app.egghead.io/api/v1/lessons/apollo-create-a-new-cache-on-every-graphql-request-using-apollo-context/transcript

https://app.egghead.io/api/v1/lessons/apollo-install-the-dataloader-package/subtitles

Instructor: [0:00] We've now built a functional DataLoader step by step showing exactly why each step is needed. This API is very close to the official DataLoader package maintained by the GraphQL Foundation, or we can install with npm install --save DataLoader. Import the DataLoader package, const DataLoader = require('dataloader').

[0:25] Then we can delete the big class we've been writing. The API matches up perfectly, so we'll already be using this DataLoader package for our userLoader. If you hover over, you can see the type signature is being pulled from the package, which we did not write ourselves. That's going to be SELECT ALL FROM users WHERE ID IN (IDs).

[0:51] We have one request for posts and one request for all of the users at once.

https://app.egghead.io/api/v1/lessons/apollo-install-the-dataloader-package/transcript

https://app.egghead.io/api/v1/lessons/apollo-fetching-an-item-by-id-with-a-graphql-dataloader/subtitles

Instructor: [0:00] Let's take advantage of the reusability of the DataLoader and clone our userLoader to make a postLoader. Make a PostResolver that takes an ID as an argument and calls postloader.load. Then to the schema, add post, ID string, returning a post.

[0:26] Try that new query out. Look at ID 2 here. We'll try to query that one specifically. Give ID 3 a shot, and everything is working wonderfully.

https://app.egghead.io/api/v1/lessons/apollo-fetching-an-item-by-id-with-a-graphql-dataloader/transcript

https://app.egghead.io/api/v1/lessons/apollo-fetching-many-items-by-key-with-graphql-dataloaders/subtitles

Instructor: [0:01] Let's add a new loader to fetch all of the comments for a given post ID. Select All from comments, where post ID is in the keys. Then we want to replace each key, each post ID, with an array of all the comments for that post.

[0:23] Under the post resolvers, add one for comments, which uses the new comments by post idLoader. Return comments by post idLoader.load post ID.

[0:35] Next, we'll add the comments field to the post schema, which returns an array of comments, and then the comment type, which has an ID, text, and an author field. We'll also need to resolve the author field on the comment type which we can just copy paste from the post type.

[0:52] Let's try querying the posts. We'll get all their comments and each ID, text, author ID, and name. No comments for the first few, looks like five comments on this one. Two comments here. All the information is right where it's supposed to be.

https://app.egghead.io/api/v1/lessons/apollo-fetching-many-items-by-key-with-graphql-dataloaders/transcript

https://app.egghead.io/api/v1/lessons/apollo-count-the-items-in-a-collection-by-reusing-a-data-loader/subtitles

Instructor: [0:02] If we want to count the comments for each post, the simplest way is to reuse our existing commentLoader and simply grab the length of the array that it returns. Let's add that to the schema, returning Int, and then test the query out. Getting a few zeros and a five, so the count is being returned correctly.

[0:26] If we are always going to query both commentCount and the list of comments at the same time, the DataLoader will batch them together, and we can essentially get the count for free with no extra database requests, which makes this the most efficient way to do it.

https://app.egghead.io/api/v1/lessons/apollo-count-the-items-in-a-collection-by-reusing-a-data-loader/transcript

https://app.egghead.io/api/v1/lessons/apollo-count-the-items-in-a-collection-with-a-custom-data-loader/subtitles

Instructor: [0:00] If users will often be querying the number of comments without also querying the list of comments, then fetching the entire comment table is wasteful. It's also not compatible with any pagination we might add later since we still need the total count.

[0:14] We can give it a dedicated comment count by post idLoader that selects post ID, counts post ID, groups by post ID, where a post ID is in keys, then maps each key to the count for that post ID, or zero if there were none. Update the resolver to use the new loader.

[0:47] You can run the query again, but it will show the same output as before.

https://app.egghead.io/api/v1/lessons/apollo-count-the-items-in-a-collection-with-a-custom-data-loader/transcript

Use GraphQL Data Loaders to Prevent Scaling Issues by Batching & Caching Database Requests

Jacob Paris

Skills you'll Gain

You might also like these resources:

GraphQL Query Language

Designing GraphQL Schemas

GraphQL Data in React with Apollo Client

Course Content

You might also like these resources:

GraphQL Query Language

Designing GraphQL Schemas

GraphQL Data in React with Apollo Client