ldlework
04/17/2018, 4:40 PMnikolasburk
info
object which is passed along to the binding function. The info
object carries the selection set of the incoming query, allowing Prisma to efficiently resolve the query!Jscott388
04/17/2018, 4:43 PMldlework
04/17/2018, 4:44 PMinfo
parameters to utilize the GraphQL nature of Prisma's CRUD, such that I'm getting back just the structure I need. Hence the GraphQL. Where as with some ORM, I'm likely always getting back full models.nikolasburk
nikolasburk
I am able to use varyingExactly!parameters to utilize the GraphQL nature of Prisma’s CRUD, such that I’m getting back just the structure I need. Hence the GraphQL.info
ldlework
04/17/2018, 4:46 PMnikolasburk
Where as with some ORM, I’m likely always getting back full models.Fetching full models is indeed a common approach when implementing your resolvers with a conventional ORM (or even when directly accessing the DB). It’s basically the “easiest” way to get your GraphQL server to work, but it entails lots of boilerplate and and also is inefficient because you’re overfetching most of the time (in those cases where clients don’t request all the fields of a type).
Jscott388
04/17/2018, 4:49 PMnikolasburk
nikolasburk
nikolasburk
Confused on the structure of the server setup. You have the database, then you have the src folder.Think of it that way. Your server is divided into two layer: API (or application) layer and database later. Each layer has its own GraphQL API and the API layer builds on top of the database layer by using bindings. The API layer is implemented in
src
, the database layer is configured in database
.nikolasburk
Jscott388
04/17/2018, 4:55 PMJscott388
04/17/2018, 5:00 PMldlework
04/17/2018, 5:04 PMJscott388
04/17/2018, 5:07 PMJscott388
04/17/2018, 5:09 PMJscott388
04/17/2018, 5:11 PMldlework
04/17/2018, 5:19 PMJscott388
04/17/2018, 5:40 PM