Fork me on GitHub
#graphql
<
2019-12-24
>
onetom05:12:23

I'm trying to understand the difference between representing queries in an uncompiled lacinia schema under the :roots :query key and under the :queries key. The https://github.com/oliyh/lacinia-gen library seems to require queries being defined under the :queries key, but com.walmartlabs.lacinia.parser.schema/parse-schema returns a schema with {:roots {:query QueryRoot} :objects {:QueryRoot {...}} Are those equivalent representations? Do they have a name, just so we can talk about them? Is there any functions which can help transforming between the 2 representations?

onetom05:12:48

Related documentation I found are: 1. https://lacinia.readthedocs.io/en/latest/roots.html 2. https://lacinia.readthedocs.io/en/latest/queries.html > Queries may also be defined as fields of the root query object. but it's still unclear how all this ties together and what's the reason for the existence of the :queries key.

onetom07:12:59

Meanwhile, I've narrowed the problem to (list (non-null :team)) in the schema causing a NullPointerException in lacinia-gen.core/generator$fn (core.clj:95) If I have the query defined under :objects {:QueryRoot {:fields {:teams {:type (non-null (list :team)) :resolve :x}}}...} then even (non-null (list :team)) causes a NullPointerException, while when defined under :queries, it works. (I'm referring to the example given at https://github.com/oliyh/lacinia-gen#query-result ) I feels like a lacinia-gen issue, but having 2 ways to define queries definitely makes things more complicated, especially if there is no way to create a unified, canonical version of the schema before compilation.

hlship18:12:16

What you are seeing is just evolution of Lacinia and the GraphQL spec. Essentially, everything under :queries is moved to a :QueryRoot object, or the object your schema specifies as the query root.

👍 2