Hi 🙂 Wondering why I can't use normally defined objects as argument types, rather I must define input-objects in the input-objects section

@jonpither Inputs cannot be cyclic while outputs (normal objects) can. GraphQL makes this explicit by requiring entirely different types.

@hlship thank you!

@hlship i was wondering about the global exception handling strategy that exists there now - is there discussion of the change somewhere in particular i should look at?

Just the PR and related issue, plus my own experience developing with Lacinia ... the 0.18.0 behavior makes it hard to track down where failures occur, since they get swallowed by Lacinia. The unreleased behavior encourages you to catch exceptions inside your non-trivial field resolvers and then use resolve-as.

that seems sensible to me - also because partial failures requires active work to support on the client

Yes, this is just Lacinia getting out of the way of things it can't take care of perfectly, delegating the application code.

in order to debug issues, i had been swap!-ing a snapshot of the context in to a dummy var and then running resolvers by hand

not sure if this makes sense, but there may be an opportunity for some public api to enable individual resolver testing

besides, you know, just calling one

for me that was just capturing the actual arguments - maybe some function that retries a resolver given an error map - or maybe i’ll just see how it goes w/ the new exception behavior

anyway, so var lacinia has been very reliable. thank you!

Great to hear that!

The other devs are good at keeping my framework-itis in check. I'm learning.

reeessssiiiiist 🙂

Would lacinia work compiling to clojurescript or is it stuck only on the jvm?

Currently JVM only, because of dependency on Antlr4. I'd like to look into opening that up a little, but it's simply not a priority at our end, and other things are.