Fork me on GitHub
#graphql
<
2018-04-24
>
eraserhd17:04:56

Hmm. So it seems we can only parallelize different attributes for an entity, and not different entities.

eraserhd17:04:33

Oh, I guess the code for an async collection can do it manually. Ahhh, OK

eraserhd17:04:34

Well that still doesn't allow lacinia to parallelize more-inner attributes,though. Hrmm.

hlship17:04:23

It will be able to do parallel work once the entire list of entities are resolved as a chunk.

hlship17:04:05

It might be possible to do this BUT we're hitting issue describing the output of a resolver function (both in terms of type signature or equivalent in code, and in terms of user facing documentation). I've been down the route (see Tapestry) of creating really concise, useful magic ... but then being unable to describe the sequence of events and operations that occur at runtime.

hlship17:04:27

In any reasonably comprehendible manner.

eraserhd17:04:52

I think I can solve this problem external to lacinia with an LRU cache of sorts, actually.

eraserhd17:04:41

This way peer objects can share results, which is part of my problem.

hlship17:04:51

Right; if Lacinia does too much, it starts to get in the way and prevent certain solutions, or violate the principle of least surprise.

eraserhd17:04:43

If I try to be sneaky, is it bad to return the same ResolverResultPromise from multiple places in the graph?

hlship17:04:03

That won't work, alas. The on-deliver! method may only be invoked once.

hlship17:04:52

But you could go down the path of returning your own implementation of the protocol.

eraserhd17:04:12

Oh, that's kind of nice, I think.