im working on a prisma2 graphql API. i'm currently writing my resolvers and I'm seeing a decision point and I'd love to get the community's feelings on best practices. when writing top level resolvers, I can either: 1. make a prisma call to the top-level object, then a second prisma call for each sub-resolver. Ex) users query calls to users model, then the personalProfile sub-query makes a call to the personalProfile model. 2. make a prisma call to the top-level object with includes statements for relational datapoints. sub-queries can use parent.* to get and return the relevant relational data. As I can see it, 1) results in many more database calls, but 2) results in more unrequested data with each database call. Does anyone have any experience or guidance in this area about best practices? For context, my database and prisma/graphql API are currently on different servers.

1) Should be assisted by Prisma’s built-in dataloader (to the degree that it resolves the N+1 problem) 2) You can be a bit smart about this if you convert the GraphQL query to a Prisma query.

@prisma-tools/prisma-select

takes this approach

Hey Spencer, that's a very valid question! I think the common way for implementing this is to follow the first approach that you've outlined. We also have an example for this here. Although I didn't fully understand this sentence of your second suggestion sub-queries can use parent.* to get and return the relevant relational data. The

parent

object typically has to be used with the first approach as well to implement the resolution of relationships in the type resolvers. An example of this is here.

See also: :)

@Jonathan Romano is

@prisma-tools/prisma-select

the same as this?

Yeah, iirc their namespace is prisma-tools

thanks for the quick responses @Jonathan Romano @nikolasburk! Jonathan - what I'm gettting from you is that both approaches can work if done properly (makes sense). I will take a look at prisma-select but if the prisma dataloader will make 1) workable, i might stick with that. Nikolas - thank you for the resources! as to the confusing statement, I meant that I can use the parent object to access any relational data fetched in the original top-level query.

No problem at all! Let me know if you have any further questions, always happy to help 🙂

will do, thanks!

Im personally considering looking into creating my own implementation of prisma-select to be a bit more flexible in handling things like ACLs, but it hasn’t gone beyond “an idea I’d like to do” 😄

@Jonathan Romano @nikolasburk Tim's video was really informative! It makes me definitely want to try out the Select plugin...50 requests per second is enticing! Plus, it seemed like it was way less code to write the resolvers. I haven't yet looked into the plugin, but if I read it right in the video, the plugin will take the graphql fields as arguments in the ...select object?