Recommend GraphQL for APIs with multiple data sources

[MalcolmTomisin]

Updated the guide to recommend using GraphQL when fetching data from multiple sources, REST APIs may suffice for simple CRUD like operations.

[JoelQ]

What is an API that pulls from different sources? Do you mean situations where you might want to read data from multiple database tables on the backend? Or do you mean hitting multiple different servers?

[MalcolmTomisin]

I mean both scenarios:

Aggregating data from multiple database tables: For example, an API might fetch user information from a users table and their purchase history from an orders table. This is typically done using database joins or similar techniques, allowing the backend to combine the data and return it via a single endpoint.

Fetching data from multiple servers or APIs: In more complex systems, data might come from entirely separate services or third-party APIs. For instance, an API might pull weather data from one service and location details from another, combining the responses before sending them to the client.

GraphQL is particularly useful in both scenarios because it abstracts the complexities of aggregation—whether it's combining data from tables or integrating multiple APIs. This allows the client to request exactly what it needs in one query, avoiding under-fetching or over-fetching data.

I hope that provided clarity on what I meant by "different sources".

[JoelQ]

Thanks for clarifying! I'm not sure either of these are properties of GraphQL itself?

The first is an API design issue. Ideally a backend doesn't expose it's database tables directly via an API. Even in a REST API, endpoints shouldn't be 1-1 with your database tables. You should be able to rename a column or split a table without affecting your API. With a properly normalized database, it's common for even REST APIs to join multiple tables in a single endpoint. In this sense, I think every API is "pulling from multiple data sources"?

That said, it's possible that a REST API won't give you everything you want in a single endpoint and that traversing the graph allows you to fetch data in a single request that might otherwise be two. I think that's the original selling point of GraphQL as a technology.

The second scenario (pulling from multiple different APIs) is interesting because I think that might be a feature of local tooling (Apollo maybe?) rather than the protocol itself? AFAICT, GraphQL as a protocol doesn't support pulling from multiple different APIs. Maybe the argument here is that the JS world has better GraphQL tooling than REST tooling so that's why we prefer GraphQL APIs?

[JoelQ]

GraphQL is particularly useful in both scenarios because it abstracts the complexities of aggregation—whether it's combining data from tables or integrating multiple APIs.

I'm curious about this idea of GraphQL as aggregation tool 🤔. I think there are two forms of aggregation happening here: aggregating data, and seamlessly issuing multiple HTTP requests.

I imagine you still need to aggregate the data once you get it back, regardless of how you get it? You almost certainly don't want data in the shape the server gives it to you, especially when combining multiple sources. I don't know that either GraphQL or REST help you here.

It sounds like like GraphQL tooling (Apollo?) can allow you to abstract over multiple requests, avoiding the need to write code like:

async enrichedPlace = (locationId) => {
  // in a GraphQL world, these two lines turn into one
  let location = await fetchLocation(locationId);
  let weather = await fetchWeather(locationId);

  // this sort of local aggregation/transformation probably still needs to happen
  // even if it's hidden inside some Apollo code
  return {
    name: location.name.fullName,
    hiTemp: toFarenheit(weather.hi)
  }
}