CODEWITHSUNDEEP
graphql
Ethan Kent
Ethan Kent

Reputation: 541

Am I misusing GraphQL if I must decompose REST data, then re-aggregate it?

We are considering using GraphQL on top of a REST service (using the FHIR standard for medical records).

I understand that the pattern with GraphQL is to aggregate the results of multiple, independent resolvers into the final result. But a FHIR-compliant REST server offers batch endpoints that already aggregate data. Sometimes we’ll need à la carte data—a patient’s age or address only, for example. But quite often, we’ll need most or all of the data available about a particular patient.

So although we can get that kind of plenary data from a single REST call that knits together multiple associations, it seems we will need to fetch it piecewise to do things the GraphQL way.

An optimization could be to eager load and memoize all the associated data anytime any resolver asks for any data. In some cases this would be appropriate while in other cases it would be serious overkill. But discerning when it would be overkill seems impossible given that resolvers should be independent. Also, it seems bloody-minded to undo and then redo something that the REST service is already perfectly capable of doing efficiently.

So—

  1. Is GraphQL the wrong tool when it sits on top of a REST API that can efficiently aggregate data?
  2. If GraphQL is the right tool in this situation, is eager-loading and memoization of associated data appropriate?
  3. If eager-loading and memoization is not the right solution, is there an alternative way to take advantage of the REST service’s ability to aggregate data?

My question is different from this question and this question because neither touches on how to take advantage of another service’s ability to aggregate data.

Upvotes: 1

Views: 144

Answers (1)

Daniel Rearden
Daniel Rearden

Reputation: 84697

An alternative approach would be to parse the request inside the resolver for a particular query. The fourth parameter passed to a resolver is an object containing extensive information about the request, including the selection set. You could then await the batched request to your API endpoint based on the requested fields, and finally return the result of the REST call, and let your lower level resolvers handle parsing it into the shape the data was requested in.

Parsing the info object can be a PITA, although there's libraries out there for that, at least in the Node ecosystem.

Upvotes: 1

Related Questions