What is the major difference between using lacinia-pedestal with async enabled, and just using async resolvers?

Does async enabled with lacinia-pedestal mean that even non-async resolvers get called async?

I would imagine just using async resolvers gives you full control over what is executed synchronously and what’s not.

I think async resolvers effect behavior internally in lacinia (it effects things like the ability to resolve fields concurrent lu) and async for lacinia-pedestal effects the behavior at the boundary between lacinia and pedestal (does pedestal block and wait for lacinia to return something, or does it treat it as async)

https://github.com/walmartlabs/lacinia-pedestal/blob/master/src/com/walmartlabs/lacinia/pedestal.clj#L345 and the function after it

oh!

thanks that makes a lot more sense

tl;dr; using lacinia-pedestal w/ async enabled frees the request processing thread while Lacinia is executing the query. Normally, the request processing thread is blocked while Lacinia is doing its thing.

So, in theory, you can handle higher levels of traffic with the same number of threads BUT you might find yourself cpu bound by doing so.

i see, that makes sense. there is a warning that the service might become oversaturated if enabled and not rate limited.