To make sure I am explicit on the fragments (I know you, Jan, know this, but bypassers will read too) in GraphQL + Relay you can write a React DOM like
query root
- fragment A
- fragment B
- fragment C
and the query gets compiled by relay to make a single request, and then each fragment only gets the data it requested (even though it was part of a larger query of data)
- Pre-filling root resolvers based on GraphQL queries ahead of time
What I have ended up doing a lot in Prisma + GraphQL to avoid db back & forths is have a large include on a Query's resolver so that it gets as much data up-front (and then sub-resolvers check if that is included or makes the db call.)
This means I'm often over-fetching or under-fetching on the db side, but also the type-safe-ness is pretty weak because it's speculative whether the includes would be there
If I could declare at a resolver level whether the data it needs can be grabbed from an include on the parent, then I could let this be fully declarative
- Data pipelining and over-fetching
I've got a lot of RichXYZ models which are just:
type RichGameWithTutorial = Prisma.GameGetPayload<{
include: { tutorialChecklist: true }
}>that are getting pretty long, and get passed through a lot of pipeline functions - it would be cool, to be able to declare what parts of those functions need from the include and have that both be respected in the types and the runtime lookup. As the include comes from a set of fns then refactors / deletions etc would be changing the includes so that it always matched the data needs of the fns.
I think both probably need some sort of pre-processing step, but it's an interesting idea I've been musing about