Fork me on GitHub
Ben Grabow17:01:56

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 }}}")

Ben Grabow17:01:48

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.

Ben Grabow23:01:04

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.


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..