GraphQL merging data from multiple REST calls

Question

I have been looking at some GraphQL implementations and what I understand is that GraphQL lets you traverse through the data in the form of a Graph.

Which means you get a list of books which is a REST call. The books might have an Author Name.

When the user wants more info on an author he says so and another REST call is made to fetch more details about that author.

Similarly the books list may have a field called Publisher and so on. So here you fetch data as if you are connecting a node of Book to a node of Author or Publisher.

But I have seen some implementations where data from two rest calls are combined using for loops and presented in the UI. e.g. make a call to REST API of Books, then make a call to REST API of Authors who have written those books. Run a for nested for-loop(n^2 complexity) to combine the result and show information of both books and authors in one single summary view.

Is this an acceptable practice or is it breaking some core concepts of what GraphQL is not supposed to do?

Daniel Rearden Daniel Rearden · Accepted Answer · 2018-10-21T01:35:21

I'm not sure I would saying doing so is "breaking some core concepts", but there is a potential disadvantage to "front loading" all your calls to the REST endpoint this way. GraphQL allows you to define a resolver for each field, which determines what value the field returns. A "parent" field is resolved before its "children" fields, and the value of the "parent" is passed down to the resolvers for each "child".

Let's say you have a schema like this:

type Query {
  book(id: ID): Book
}

type Book {
  title: String
  author: Author
  publisher: Publisher
}

Here, the book field would resolve to an object representing a book, and that object would be passed down to the resolvers for title, author, and publisher.

If no resolver is provided for a particular field, the default behavior is to look for a property on the parent object with the same name as the field and return that. So, your resolver for book could fetch both the book, the author and the publisher from some REST endpoint (3 calls total) and returned the combined result. Alternatively, you could just fetch the book, and let the author field resolver fetch the author and the publisher field resolver fetch the publisher.

They key is that a resolver is only called if that field is requested. The difference between these two approaches is that you could potentially query a book and only request the title.

query SomeQuery {
  book(id: 1) {
    title
  }
}

In this scenario, if you front load all your API calls, then you're making two additional calls to the REST endpoint (for the author and the publisher) unnecessarily.

Of course, if you have a field that returns an array of books, you may not want to hammer your REST endpoint by fetching the author for each book requested, so in those situations it may make sense to fetch both books and authors all in the root query.

There's no one right answer here, since there may be trade-offs either way. It's a question of how your schema is designed, how it will be used and what costs are acceptable to you.

GraphQL merging data from multiple REST calls

1 Answers