FYI https://lacinia.readthedocs.io/en/latest/resolve/async.html

I know about this, but this is about resolving an individual field/value. I can’t see how this can give me any control over the parallelism of nested resolvers

There is https://github.com/vlaaad/plusinia that allows parallelizing (and batching) resolution process, at the expense that you have to opt-in for every resolver to work on a set of values instead of a single value

Ah, you know about it already..

I think in my case I have an alternative. My return value is actually [{:node v1} {:node v2},,,] (think Connection like result https://graphql.org/learn/pagination/#complete-connection-model). So I can make the resolver for :node return a promise which I immediately (asynchronously) deliver, and then I know the on-deliver chain of resolvers lacinia attaches will run in parallel. That’s enough parallelism for me in this case. It seems to work! I deliver the promise value using an agent send, but set the *callback-executor* to the agent send-off threadpool because those other resolvers may involve IO.

If I didn’t have that extra nesting via the :node field to rely on, I’m not sure what I could have done here.