-
Notifications
You must be signed in to change notification settings - Fork 846
Description
Lets say you have a list of movie, each movie have a list of actor, producer and director. And each actor have a list of movie their acted in. If we draw this like a tree, it would look like this:
Movies
| - Movie
| | - Actors
| | | - Director
| | | | - Movies
| | | | | - Movie
| | | | | - Movie
| | | - Actor
| | | | - Movies
| | | | | - Movie
| | | | | - Movie
| | | - Actor
| | | | - Movies
| | | | | - Movie
| | | | | - Movie
| | | - Actor
| | | | - Movies
| | | | | - Movie
| | | | | - Movie
| - Movie
| | - Actors
| | - Actors
| | - Actors
| - Movie
| | - Actors
| | - Actors
| | - Actors
The current implementation of the query resolves each item separately. If each resolver were to resolve by a database query. Let the number of movies is N, actors have joined M movies in average, directors have P movies in average. Then the above graph will be consist of:
- List of Movies (1)
- Movie - Director (N)
- Movie - Director - Movie (N x P)
- Movie - Actor (N)
- Movie - Actor - Movie (N x M)
And the number of queries goes up exponentially.
From what I read in other source, NodeJS server implementations usually have a loader layer (such as facebook/dataloader to help reducing the number of data fetching query. This pattern rides on the execution sequence of NodeJS (resolves all promise before return).
So the above graph would result in this
- List of Movies (1)
- Movie - Director (1)
- Movie - Director - Movie (1)
- Movie - Actor (1)
- Movie - Actor - Movie (1)
The key is to gather all specify the entities to load when doing resolve, then resolve them in 1 single batch. Also with a load of caching, the number of entities to query can be even drive down.
The question is, how do you similar thing in graphql-go?