graphql

chrisulloa 2020-02-10T20:41:22.046200Z

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

chrisulloa 2020-02-10T20:41:44.046800Z

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

chrisulloa 2020-02-10T20:42:23.047200Z

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

2020-02-10T20:54:13.052500Z

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)

chrisulloa 2020-02-10T21:19:52.053300Z

oh!

chrisulloa 2020-02-10T21:24:02.053500Z

thanks that makes a lot more sense

hlship 2020-02-10T21:39:24.054400Z

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.

⭐ 2
hlship 2020-02-10T21:39:58.055Z

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.

chrisulloa 2020-02-10T22:45:20.055600Z

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