Skip to content

Instantly share code, notes, and snippets.

@orta
Last active June 16, 2024 12:13
Show Gist options
  • Save orta/07f3c142fe3708cabad0c08fb5a5a284 to your computer and use it in GitHub Desktop.
Save orta/07f3c142fe3708cabad0c08fb5a5a284 to your computer and use it in GitHub Desktop.
Prisma include fragments

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)

I have two general data-fetching smells which I had been thinking about
  1. 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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment