Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommend GraphQL for APIs with multiple data sources #714

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Recommend GraphQL for APIs with multiple data sources #714

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions react/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,9 +45,10 @@
- For greenfield React projects we like to use [TypeScript]. TypeScript is a
typed superset of JavaScript that compiles to plain JavaScript. For a quick
introduction, check out [TypeScript in 5 minutes].
- If our app needs to make network requests and hold state outside of a
component, we like using GraphQL and our preferred library is [Apollo]. We
have a [section on `GraphQL`](/graphql) in our Guides.
- When designing an API that requires pulling data from multiple sources, we
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)
  }
}

recommend using GraphQL for more efficient and flexible data fetching. Our
preferred library is [Apollo], and for more details, you can check out our
[`GraphQL`](/graphql) guide.
- When building React apps with TypeScript and Apollo, we've found working in
[VSCode] to be a mostly-good experience.

Expand Down