I'm working through the Lacinia tutorial and I'm stuck on the step where we begin to wire up transitive resolvers. My code looks right as far as I can tell, but when I query make the following query I get :designers [nil nil]
instead of the actual designer names.
(q "{ game_by_id(id: \"1237\") { name designers { name }}}")
We've tried to avoid using any logging because our logging choices may not be your logging choices. Eventually we may need to bite the bullet and I would lean on io.pedestal/pedestal-logging.
It's a shame there is not really a default, like with Java. Although with Java it sometimes happen the Log implementation is included in the library. But even there, not having a clear distinction between different log levels means you often need to fine-tune logging to make it useful..
I'm at this step: https://lacinia.readthedocs.io/en/latest/tutorial/designer-data.html
Aside from solving this specific problem I'm curious if there are general suggestions for debugging problems like this. I'm a bit new to graphql in general and lacinia in particular so I don't know where to start investigating how my resolvers are working behind the scenes.
Since your new to GraphQL, are you aware of the GraphiQL that's included in lacinia-pedestal, it's great for trying out things. There are some example projects in the docs, but not sure if any is using transitive resolvers.
Not sure if I'm using the right terminology, by by transitive resolvers I just mean a parent object has a field that itself has a resolver and its own fields. Turns out I was missing the :resolver
key inside the parent's field, but I figured it out by comparing to the example schema in the tutorial and I'm not sure how I would have debugged it if I were working on a real project. Is there a way to trace what the lacinia query engine is doing, a debug mode or something?
Good to hear it's resolved. I'm not sure it's the right terminology either, but it's how I understood it. Only used Lacinia with a flat data model. Not sure if there's a debug mode.