I think you are still mixing database concepts and data representation.
Roman Krivtsov

Can you list some of those rich advantages? I understand that I can build a REST endpoint that sends

user {
pets: [...]

But I might have disparate needs for user requests. Sometimes I just want a user’s email, sometimes I want their profile image, sometimes I need their number of pets, sometimes I need the pets themselves, sometimes I need all of that or only parts.

My REST options are:

  1. Build an endpoint for each usecase
  2. Build a single endpoint that covers all the use cases, and let clients filter down the data to what they actually want
  3. Build individual resource endpoints and let clients do the map logic I already described.

But all of those are awkard and have huge disadvantages.

My GraphQL options include:

  1. Define entity types with resolvers that point to other types. Now clients can just say what they want and get it back in one request.

Is there any way for me to get that for free by wrapping an existing REST API? I’m hearing you say no, which makes me wonder what I _do_ get.

Show your support

Clapping shows how much you appreciated Joe Fraley’s story.