Fork me on GitHub
#pathom
<
2019-09-12
>
kenny17:09:19

Is it ok to have blocking operations in a resolver/mutation when using the parallel parser?

souenzzo18:09:04

@kenny no. It will freeze your system sometimes a dummy solution is wrap your blocking ops with a thread https://github.com/souenzzo/graph-demo/blob/master/src/main/souenzzo/graph_demo/core.clj#L99

kenny18:09:37

Hmm. That seems a bit sketchy.

wilkerlucio18:09:39

@kenny if you use the thread pool feature, its ok

wilkerlucio18:09:56

the thread pool thing will run resolvers in a dedicated thread pool, so they wont block the go block threads

kenny18:09:23

@wilkerlucio Oh cool! So then you don't need to return a core.async thread from each resolver, right?

wilkerlucio18:09:43

even if you don't use the thread pool, its ok to return strait values

wilkerlucio18:09:55

the thread pool just ensures you are not blocking the go threads

4
kenny18:09:26

And the benefit over the regular parser is that the resolvers are run in parallel, right?

wilkerlucio19:09:08

@kenny just a caveat, tune that number, nowadays I believe 200 is too much, at Nubank we are running pretty big instances with 100 and its been fine

wilkerlucio19:09:42

depending on how much concurrency you are expecting it may be good to bump the Go thread pool as well (core.async default is 8, we are using 32)

kenny19:09:51

The go thread pool wouldn't need to change if I'm passing a thread pool to Pathom, correct? We don't really use go blocks.