Thus… you have to re-do all the resolvers?

Great question! Please take a look at this blog. https://www.prisma.io/blog/graphql-server-basics-demystifying-the-info-argument-in-graphql-resolvers-6f26249f613a/ If you have any questions, please let me know

@lawjolla Ok, so taking this a step further… Say the

User

type has a

firstName

and a

lastName

field. Yet the API wants to expose

fullName

and concatenate the two. If the query coming in is simply:

query { user(id: "X") { id fullName } }

then the resolver for

fullName

will fail, as it doesn’t have access to

firstName

and

lastName

. Now… You could re-query the

user

in the resolver, but a 2nd DB query seems overkill. Is there no way to say “if the user queries for

fullName

ensure that

firstName

and

lastName

are returned from Prisma, regardless of whether they were in the original query?”

You are correct. And no, to my knowledge, there is no way -- it will take multiple queries. As an aside, when I started with GraphQL, I had an issue with this overfetching. But abstraction layers come with a cost. GraphQL by its nature cannot use a REST-esque single SQL query per request. I've found the tradeoff more than acceptable, but your mileage may vary. The great part about GraphQL is there's always an escape hatch... if you have, say, a query that's too expensive for nested resolvers, you can create a single purpose query and in that resolver write a SQL query and hit the database directly. I know a lot of people are doing that for aggregation queries.