Fork me on GitHub
#graphql
<
2018-10-07
>
devth21:10:53

i'm unclear on a very basic concept: will Lacinia auto resolve nested queries, e.g.:

history {
  id
  body
  user { id name }
}
or would this require that my history-resolver manually invoke the user-resolver?

devth21:10:23

the history-resolver knows the user-id but i don't know how it would pass it to user-resolver unless there is some convention i'm missing

devth21:10:59

kinda weird because that means i'd need two resolver functions: one that takes :id out of the args i.e. get-user-by-id and another that takes :id out of the value (3rd arg) depending on whether it was a top level query or part of nested resolution. 🤔

hlship17:10:45

In general, Lacinia doesn't know anything about where your data is stored or how to get it. That's entirely the domain of your resolvers. There's a trivial but useful case: where the field name matches a key of a resolved value (a map or record), in which case, Lacinia supplies a default resolver function automatically. The id arg and the id field are quite different. In one case, it is passed into your resolver function, so that data can be obtained from an external store. In the other, Lacinia is supplying a default resolver for you, to extra a selected field from a resolved value (the very resolved value that your earlier resolver function provided).

hlship17:10:42

The fact that it's an arg named id and a field named id is a coincidence.

devth17:10:57

got it. starting to make sense 🙂

devth17:10:18

pretty awesome too. previously i was only using top-level resolvers.

hlship17:10:24

Often it is convienient to resolve values in one "shape" (defined by your storage) and have additional nested resolvers to re-shape the data as needed. For example, we expose data that is partly stored in our database, partly obtained from an internal 3rd party. So if you are using some of that 3rd party data, the top-level resolvers will fetch it in a block (to avoid N+1 external calls) but then other resolvers will fold that raw data into the shape defined by the GraphQL schema (the 3rd party is incomprehensibly verbose).

devth17:10:31

makes total sense :+1:

devth21:10:21

of course one fn could inspect both 🤔