Hi folks, I have a general question regarding the ...
# orm-help
j
Hi folks, I have a general question regarding the nr of database calls when using prisma in a graphql app (Nexus schema based). Are there strategies or so for accomplishing Scenario 1 in the following example in a clean way:
Copy code
# Scenario 1: Do a single Prisma call on Posts-level (Level A)
{
    posts { # <-- Level A: Do a single prisma.many call, and actually include all users, profilePictures, with all of their
        users { # <-- Level B❓On the user-resolver, do we then have to do a superfluous another call (even if level A already got all of their info?)
            name
            title
            birthDate
            derivedNrOfFriends
            profilePictures {  # <-- Level C ❓On the profilePictures resolver, do we do a call even if the posts already included everything necessary?
                ...etc
            }
            friends {

            }
        }
    } 
}

# Scenario 2: Do multiple Prisma call on each resolver (Level A, Level B, Level C)
{
    posts { # <-- Level A: Do a prisma.many call, only include post fields
        users { # <-- Level B❓Do a prisma.many call, only include user fields, use optionally parent.id to scope on posts
            name
            title
            birthDate
            derivedNrOfFriends
            profilePictures {  # <-- Level C. Do a prisma.many on profilePictures resolver level, use optionally parent.id to scope on users
                ...etc
            }
            friends {

            }
        }
    }    
}
Currently we do the second one, but it stands to reason that the number of database calls would be more optimal if instead we would use a resolver’s
info
property or set
context
in some way to inform resolvers on a lower level that their information is already gathered. However, when calling users independently (without posts as parent), they would need to do their own prisma calls
Though if you think the performance in nr of database calls is neglible, then that would be a great insight nonetheless
r
Hey Jonathan 👋 For looking at how many calls are made by Prisma to fetch data, you can use the below snippet:
Copy code
const prisma = new Prisma.PrismaClient({
  log: ['query'],
})
This will log all database queries made. Right now, some performance optimizations are still to be complete so you would notice improvement over time for these as well 🙂
j
Hey Ryan, thanks for jumping in :). Would you say that at runtime there are good strategies to look at what data you already retrieved for a query (higher up in the graph, so from profilePicture look and see if user already got its data), or would you go with firing prisma on each separate resolver field?
r
I would suggest making a single query via Prisma using
include
for relational data as Prisma will handle the optimizations internally and you do not need to worry about firing Prisma separately on each resolver.
j
Exactly, and then build the single query based on what relations are requested based on the ‘info’ object, so that it wont always call these relations unless requested
💯 1
At least that seems like the best mental model I can currently think of for this performance. Thanks Ryan!
👍 1